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Abstract 


Available constraint programming languages like Prolog-Ill, CHIP, CLP(R) and 
CAL do not completely separate the inference engine and the constraint solver. 
Substantial work is needed to construct a new CLP system from these existing ones 
because these languages were constructed for specific problem domains. 

A number of general purpose solvers like Mathematica and REDUCE are already 
available on different kinds of machines. These pre-existing solvers are very good at 
solving constraints over specific domains for which they are designed. In this report 
we describe a CLP system which directly uses already available solvers by explicitly 
separating logical inference from constraint satisfaction. 

The constraint solvers are attached separately in the form of independent mod- 
ules to check the satisfiability of the constraints and find the corresponding solu- 
tions. A general interface is defined between the inference engine and the constraint 
solvers to support pre-existing solvers as well as custom built solvers. A number 
of independent solvers can be distributed across heterogenous CPUs. A new CLP 
system can be constructed simply by attaching the required constraint solvers for 
particular problem domains of interest over the defined interface. 

The user of the CLP system specifies the domain and the constraints in his 
application. The use of constraint solvers is transpajent to the user. The constraint 
solver server on the client side allocates solvers from amongst the available ones to 
the application as needed. The execution site for the constraint solvers is selected 
dynamically by the user thus providing both good performance and generality. 



Chapter 1 

Introduction 


In this chapter, we discuss the motivation behind the present work. We also provide 
a brief overview of work done and finally discuss the organization of the thesis. 


1.1 Motivation for Present Work 

Constraint logic programming languages like Prolog - III [9, 10], CHIP [12], CLP(R) 
[15, 16] etc. are tightly coupled with the constraint solvers. These implementations 
have a fixed structure. Since they were designed with a specific structure in mind, 
the inference engine and the constraint solvers have not been completely separated. 
Addition of new domains to such systems is very difficult and time consuming. 

Meta-interpreters written in logic programming languages may be used in imple- 
menting experimental CLP systems. The meta-interpreter approach [18] simplifies 
the handling of resolution steps in the CLP language but requires solvers to be 
written in a logic programming language. Often the solvers are not efficient - and 
this together with the meta-interpretation overhead produces very slow systems in 
general. 

A Constraint Logic Programming Shell for rapid implementation of CLP systems 
has been described in [27]. They have discussed the use of special predicates for use 
by solvers assisting in the construction of a CLP system. 

Our aim has been to design an interface for coupling different kinds of solvers 
to the Inference Engine. The constraints are considered to be built in predicates 
handled by the constraint solver. Our system is designed to provide the advantages 
of the meta interpreter approach, without some of the speed drawbacks. We have 
explicitly separated the logical inference steps and structure satisfiability questions. 
Our system is different from those mentioned above in that the solvers are attached 
at run-time rather than having a system with fixed constraint solvers. Since there 
are many pre-existing solvers already available, we allow these to be incorporated 
in the CLP system rather than requiring a specially written solver. 
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1.2 Overview of Work Done 


The stages involved in designing the Modular Distributed Constraint Logic Pro- 
gramming System are illustrated in Figure 1.1. 

First, a Constraint Logic Programming language wa.s defined and an interpreter 
was developed on top of IF /Prolog using the meta interpreter approach for domain 
‘real’. This was used in studying the way new domains could be added to create 
a general system. In the process, black box constraint solvers were designed and 
implemented for the domains ‘real’ and ‘boolean’. 

A simulator was written in Turbo Prolog for the Vienna Abstract Machine 
(VAM). Most of the Prolog predicates including the asserta, assertz, retract, univ 
operator, call and execute were implemented. A list of the internally defined pred- 
icates implemented is given in Appendix A. Some examples using these predicates 
are listed in Appendix C. The VAM simulator was tested by checking the execu- 
tion of the constraint solvers implemented for IF/Prolog for a number of examples 
directly on this VAM simulator. An operator precedence parser and code generator 
were implemented in Turbo Prolog for converting programs to VAM code. 

We ported this implementation on to Quintus Prolog on SIJN-3 machines from 
Turbo Prolog because of memory limitations of DOS. After some minor modifi- 
cations (because of Occur Check), the Constraint Logic Programming Interpreter 
written earlier, was executed directly on top of the VAM simulator. In this imple- 
mentation, the solvers were also executing on top of the VAM simulator making the 
execution very slow. Refer to Figure 1.2. The exact structure was as follows : first 
the VAM-simulator in Quintus Prolog, second the meta interpreter executing on the 
VAM-Simulator along with the constraints solvers and third the programs meant 
to be executed on the meta interpreter (e.g. The Pigeons and Rabbits Problem, 
Installments Problem, Light Meals Problem, etc). 

We modified and extended the VAM to define a structure independent inference 
engine as shown in Figure 1.3 which currently forms the core of our CLP system. 
A separate compiler was written in C (YACC and LEX) for compiling the Pro- 
log Programs with constraints to Vienna Abstract Machine Code. In the current 
implementation, the code produced by this compiler for clauses written by a user 
is loaded by the simulator. The Prolog compiler is however used to compile user 
queries when the user interacts with the system. The constraint solvers mentioned 
in the above paragraph were separated from the Constraint Logic Programming 
Meta Interpreter and were directly executed on top of Quintus Prolog as shown 
in Figure 1.3. These are now accessed through an interface thus increasing the 
execution speed. 

The first version of the implementation of the CLP system is operational. To 
check the working of the interface for different kinds of solvers, we have also imple- 
mented an incremental solver for domain ‘real’. The novelty of our CLP system in 
its current form is that new solvers can be introduced in a completely modular and 
incremental way. They could even be running on a machine other than the one on 
which the inference engine is running. A Constraint Solver Server and an Advice 
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Stage I 

Pure Prolog 
Interpreter in C 


Stage II 

Meta interpreter for 
Prolog in IF/Prolog 

Solver using Simplex 
method in C 

Stage III 

VAM Simulator in 
Turbo Prolog 


Delaying incorporated 
using freeze predicate 


Constraints 

incorporated 


I 


Constraint Solvers using term rewriting in 
IF /Prolog for domains real, boolean and list 


Compiler in Turbo Prolog for compiling 
clauses and queries to VAM code 


Stage IV 



Stage V 

Interface modified for using external black box solvers on independent 
machines with the help of dictionary using ‘rpc’ and ‘sameJs’ . 

Solvers of stage II modified to accept commands from other machines 


Stage VI 

Constraint Solver Server and Advice Database designed for using 
internal solvers and also the external solvers distributed over the network 


Implemented incremental solver 
for domain real 


Modified dictionary to handle 
incremental solvers 


Figure 1.1: Stages in the design of the modular distributed CLP system 
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Figure 1.3: Using Internal Solvers 
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Figure 1.4: Using External Solvers 

Database have been designed. The routing of the constraints to their respective 
solvers is handled by the constraint solver server which is transparent to the user 
by the use of an advice database, where information about solvers is maintained. 
This is illustrated in Figure 1.4. 

1.3 Outline of Thesis 

The rest of the thesis is organised as follows : 

A brief review of Prolog, Logic Programming and Constraint Logic Programming 
is presented in Chapter 2. The meta-interpreter approach used for designing a CLP 
system is described in Chapter 3. The details of the CLP system meta-interpreter 
implemented earlier a.s a step towards building the final system have been explained 
in this chapter. The facilities provided in the final system to write constraint logic 
programs have been explained with examples in Chapter 4. In Chapter 5, we have 
given an overview of the Vienna Abstract Machine. We have also covered the 
implementation aspects of the Vienna Abstract Machine on top of Prolog. We have 
described the Inference Engine in detail in Chapter 6 where extensions made to the 
VAM are also discussed. The compilation aspects have been covered in Chapter 7. 
The different kinds of Solvers have been dealt with in Chapter 8. The Solvers to 
be interfaced to the Inference Engine may be present either on the client machine 
or any of the server machines. This chapter deals with the invocation details and 
backtracking in the solvers. In Chapter 9, the Constraint Solver Server present on 
the client machine has been detailed. Its work is to make use of the advice database 
for allocation of constraint solvers. The Interface has also been explained in this 
chapter. Adding of solvers is illustrated with the help of examples in Chapter 10. 
Finally we have listed the applications and made suggestions for further work in 
Chapter 11. 
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Chapter 2 

Review of Constraint Logic 
P rogramming 

2.1 Logic Programming and Prolog 

Prolog, an acronym for Programming in Logic, was created at the Faculty of Sciences 
at Luminy in Marseilles, France. The creators’ original objective was to integrate 
a development in mathematical logic - the resolution principle proposed by Robin- 
son into a programming language. Robinson’s resolution principle suggested the 
application of only one powerful rule of inference to mechanical theorem proving. 
This facilitated the design of a programming language that would enable a pro- 
grammer to make a computer simulate the thinking process by making deductions 
from information given in logical formulas. A tutorial of a succession of proposed 
logic programming schemes has been discussed in [6]. Prolog has been considered a 
model for designing the computers of the future [8]. 

Logic Programming is very appropriate to state constraint search problems. Its 
relational form and the logical variables are very appropriate to formulate such 
problems in a declarative way and its nondeterministic computation liberates the 
user from tree search programming. However, Prolog is too inefficient to tackle 
Icirge search problems. 

Prolog has at least two attractive features to be used in constraint problems : 
expressiveness and unification. However, its simple backtrack search and its lack 
of data-driven computation makes Prolog inefficient in most cases. The general 
computational paradigm of Prolog is “generate-and-test”. This is elaborated in 
Chapter 4. 


2.2 Constraints 

Given a computation domain, a constraint expresses a relationship between some 
objects of this domain. Constraint manipulation and propogation have been studied 
in the Artificial Intelligence community in the late 70’s and early 80’s especially in 
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the USA. They provide very interesting problem solving techniques like local value 
propogation, data driven computation, sophisticated search algorithms (e.g. for- 
ward checking) and consistency checking. The general idea behind these techniques 
is the use of constraints to prune the search space in an ‘a priori’ way, i.e. before 
the generation of values. 

The most outstanding feature of constraint programming [26] is that it allows 
the declarative description of problems which are solved by indicating a goal without 
reference to the method by which it should be established. Constraints in a program 
are evaluated automatically and affect the execution of the program depending on 
their meaning. 

Three operations can be distinguished on constraints : 

1. Constraint Formulation is the adding of new constraints as commitments in 
the design process. A problem solver that can introduce new constraints need 
not work with all of the details at once. This idea is consistent with the com- 
mon experience of working on problems that are imprecisely formulated, but 
which become more tightly specified during the solution process. In contrast, 
the traditional constraint satisfaction approach works with a fixed number of 
constraints that axe all known in the beginning. 

2. Constraint Propogation is the creation of new constraints from old constraints. 
When constraints are propogated, they bring together the requirements from 
separate parts of the problem. Constraint propogation makes possible a least- 
commitment strategy of deferring decisions for as long as possible. The prob- 
lem solver works to keep its options open, and reasons by elimination when 
constraints from other subproblems become known. 

3. Constraint Satisfaction is the operation of finding values for variables so that 
a set of constraints on the vaxiables is satisfied. When the constraints and 
variables come from different subproblems, constraint satisfaction plays a co- 
ordinating role by pooling the constraints and intersecting their solutions. 

2.3 Constraints in Logic Programming 

Constraints are incorporated into logic programming [11, 7, 19, 24] to increase the 
descriptive power of logic programming. Extensive work has been conducted in 
this direction especially in Europe (Marseille, European Computer- Industry Re- 
search Center), USA (IBM Yorktown Heights), Camada (Vancouver) and Australia 
(Monash University). The general idea behind the introduction of these extensions 
inside logic programming is the use of some mathematical tools to solve numerical 
constraints and the use of consistency checking and constraint propogation tech- 
niques to solve symbolic constraints. Active use of constraints helps in reducing 
the search space of large search problems as much as possible. The advantage of 
constrained terms is the increase in efficiency obtained by testing the constraints as 
soon as possible. 
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Prolog-II [13] provides delaying of subgoaJs with the freeze/2 predicate. Thus, 
freeze(X,P) is the same as call(P), except that P will be executed only when X is 
bound to a non-variable term. X is called the freezing variable and P the frozen 
goal. Lot of work has been done in order to provide a coroutining mechanism which 
allows modification of the computation (control) rule. Refer to Appendix C.9 for 
use of freeze predicate in this manner. 

Prolog-Ill [10, 9] uses a simplex-like algorithm to solve linear equations and 
inequations on rational numbers for linear programming purposes. It also provides 
a saturation method to deal with boolean terms. 

CLP(R) [15] handles linear equations and inequations over real numbers. A 
modification of the standard simplex algorithm which serves as a CLP(R) constraint 
solver has been presented in [21]. 

CHIP [12] works on finite domain restrictive terms, boolean terms and linear 
rational terms. 

CAL (Constrainte Avec Logique) [2] supports the writing and solving of linear and 
nonlinear algebraic polynomial equations, boolean equations and linear inequalities 
as constraints. 


2.4 The CLP scheme 

The CLP scheme [20] is not an extension to logic programming but provides a 
general framework from which Prolog extensions can be derived. The unification 
algorithm, the heart of a Prolog interpreter, is itself a particular case of constraint 
solving. It tells us whether two terms, such as f(x,a) and f(b,y), can be made 
identical by a particular instantiation of the variables (here x=b and y=a). In other 
words it decides whether the equation f(x,a)=f(b,y) is solvable and in the process 
outputs a substitution that explicitly represents the set of all solutions. This finite 
explicit representation although a strength of unification, is also its weakness since 
for many domains of interest, such finite explicit representations do not exist, and 
therefore the concept of unification is not sufBcient. 

Consider a simple Prolog program to compute factorial as shown below : 

fact(N,F) :-N>Q, 

fact((iV - 1),M), 

F = N*M. 

fact(0,l). 

A query such as : 

?- fact(3,F). 
returns the answer F = 6. 

To achieve this answer, Prolog goes through a number of steps, which can easily be 
expressed in terms of solving constraints. 

Four sets of constraints are obtained : 
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Cl = {3 > 0, F = 3 + M1} 

C2 = Cl and {2 > 0, Ml = 2 * M2} 

C3 = C2 and {1 > 0, M2 = 1 * M3} 

C4 = C3 and {0 = 0, M3 = 1} 

The first three sets of constraints come from the first clause of the program and 

have no explicit solutions. The fourth set however can be solved using the second 
clause, and its solution provides the answer. 

Thus a Prolog program can be thought of as a constraint-solving problem. A 
CLP program for factorial will be same as above. However, there is a fundamental 
difference between a normal Prolog program and a CLP-program. In the case of 
the Prolog program, if the factorial function is reversed, i.e., asking for the number 
whose factorial is say 6, 

?- fact(N,6). 

the subtraction operation in Prolog works only if its arguments are instantiated, 
and in this case the factorial program contains the expression A — 1, where N has 
no value. In CLP, however, this problem does not arise and we get the expected 
answer. Note that it is possible to rewrite the Prolog program without this operator 
by using the successor function (•s(A’) = X -f 1), this creates different problems of 
checking for all possible values. Refer to Appendix F.l for the factorial program 
using constraints along with all test cases for using the same. 

Solving a goal is defined in terms of solvability of the set of constraints and not 
in terms of finding a value. The execution steps of CLP programs depend upon 
whether or not a constraint is satisfiable in a given domain. 
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Chapter 3 


Meta-Interpreter for 
Constraint Logic Programming 


Meta-programs treat other programs as data. They analyze, transform, and simu- 
late other programs. The writing of meta-programs, or meta-programming is par- 
ticularly easy in Prolog due to the equivalance of programs and data : both being 
Prolog Terms. 

A Meta-interpreter for a language is an interpreter for the language written in 
the language itself. The ability to write a meta-interpreter in Prolog enables the 
building of an integrated programming environment for CLP by giving access to 
the computational process of Prolog. 

We describe in this chapter, the meta interpreter we have developed in IF-Prolog 
before discussing the CLP system implementation on an Abstract Machine. In the 
meta-interpreter, we directly use all the system predicates provided by IF-Prolog. 
We have provided predicates for delaying of goals and for specifying constraints. 
The clauses are specified by the user directly in IF/Prolog. 

3,1 Meta interpreter for Prolog 

The Prolog procedure solve uses the built in predicate clause (Goal, Tail), which 
determines the (first) head of a Prolog rule that unifies with Goal and binds Tail 
to the tail of that rule. In the case of unit clauses, Tail is bound to true. The 
meta-interpreter takes the form : 

solve (true) . 

solve ([Goal I RestGoal]) solve (Goal) , solve(RestGoal) . 

solve(Goal) clause(Goal,Tail) , solve(Tail). 


3,2 Incorporating Freeze 

To incorporate freeze, two additional parameters are needed: the list represent- 
ing a current Freezer and another list representing its modified counterpart, the 
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NewFreezer. Both lists contain pairs (variable, goal) in which variable is an unbound 
(or frozen) variable and the goal is a term to be activated as a procedure as soon 
as the variable becomes bound (or unfrozen). Immediately after a clause matches a 
Goal in the database, the defrost predicate is used to check whether any variable has 
thawed, in which case the corresponding goal is immediately solved after updating 
the Freezer. This is shown below : 

solve (true, Freezer, Freezer) . 
solve ( [Goal iRestGoal] , Freezer, NewFreezer) 
solve (Goal , Freezer , TempFreezer) , 
solve (RestGoal , TempFreezer , NewFreezer ) . 
solve (Goal , Freezer , NewFreezer ) : - 

clause (Goal, Tail) , defrost (Freezer, TempFreezer) , 
solve(Tail , TempFreezer , NewFreezer) . 
solve (fre6ze(X, Goal) , Freezer, [[XlGoal] 1 Freezer]) 
var(X) . 

solve (freeze(X, Goal) , Freezer, NewFreezer) 
nonvar(X) , solve (Goal, Freezer, NewFreezer) . 
defrost (□,□). 

defrost ( C [X | Goal] | Freezer] , C [X | Goal] | NewFreezer] ) : - 
var(X) , defrost (Freezer, NewFreezer) . 
defrost ( C [X I Goal] I Freezer] , NewFreezer) : - 
nonvar(X) ,defrost(Freezer, TempFreezer) , 
solve (Goal , TempFreezer , NewFreezer) . 

Notice that in the backtracking mode, thawed procedures should be refrozen. 

3.3 Disequalities 

Freeze can be used in “simulating” another useful Prolog extension : dif(X, Y) or 
X \== y. Although this predicate is available on most interpreters, it is applicable 
only when both X and Y are bound. If even one of the variables is unbound, the 
interpreters return failure. The more general dif could be programmed using the 
clause : 

dif(X,Y) freeze(X, freeze(Y, different (X ,Y)) ) . 

in which different(X, Y) would test whether or not the bound variable X is different 
from the bound variable Y. 


3.4 Incorporating constraints 

Two more parameters : the list representing the current set of constraints Previ- 
ousConstraints and another representing the new list of constraints NewConstraints 
are incorporated. The listing of the meta interpreter for our CLP system is shown 
below : 
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/* metaclp.pro */ 

/♦ CLP met a- interpreter in IF/Prolog on HP-9000 machine */ 

: - [constraint] . % calling the constraint solvers 
[xprn] . */, float constraint solver 

; - [f loateqn] . 

[booleaneqn] . */, boolean constrant solver 
[listeqn] '/, list constraint solver 

solve (true , FrozenGoals , FrozenGoals , Constr , Constr) : - 
! . /* for unit clause */ 

solveC’ , ’ (Goall.Goal) , FrozenGoals, NewFrozenGoals , 
PreviousConstraints.NewConstraints) !, 
solve (Goall .FrozenGoals .TmpFrozenGoals, 

PreviousConstraints .TmplConstraints) , 
solve (Goal .TmpFrozenGoals .NewFrozenGoals , 

TmplConstraints .NewConstraints) . 
solve (freeze(X, Goal) .FrozenGoals, [[XlGoal] | FrozenGoals] , 
Constraints, Constraints) var(X),!. 
solve (freeze (X , Goal) , FrozenGoals .NewFrozenGoals , 
PreviousConstraints .NewConstraints) : - 
nonvar(X) , ! , 

solve (Goal , FrozenGoals , NewFrozenGoals , 

PreviousConstraints .NewConstraints) . 
solve (Goal .FrozenGoals .NewFrozenGoals , 

PreviousConstraints .NewConstraints) : - 
clause(Goal,Tail) , 

solve_thawed(FrozenGoals .TmpFrozenGoals , 

PreviousConstraints .TmpConstraints) , 
convert (Tail .TmpFrozenGoals .NewFrozenGoals , 

TmpConstraints .NewConstraints .ReplacedTail) , 
ReplacedTail. 

solve (Goal, FrozenGoals, FrozenGoals, Constraints .Constraints) 

/* This rule is required for preventing the flow of control to 
go to the next "solve" if all user defined clauses of Goal 
(if present) have failed. If no user defined clauses are 
present, the control passes over to the next "solve" to 
execute the goal as a normal prolog Goal. The cut in this 
"solve" after "clause" cannot be present in above "solve" 
after "clause" since it prevents normal backtracking of 
"clause". 

*/ 

clause (Goal, Tail) , ! .fail, 
solve (Goal .FrozenGoals .FrozenGoals . 


12 



Constraints .Constraints) call (Goal) . 


/♦ Solve the goals which have got unfrozen */ 
solve.thawedC [] ,0 .Constraints, Constraints) :-! . 
solve_thawGd([[X|Goal] I FrozenGoals] , 

C [X I GoalJ-l NewFrozenGoals] , 

PreviousConstraints .NewConstraints) : - 

var(X) , ! , 

solve.thawed (FrozenGoals .NewFrozenGoals , 

PreviousConstraints .NewConstraints) . 
solve_thawed(C[XlGoal] 1 FrozenGoals] .NewFrozenGoals, 
PreviousConstraints .NewConstraints) : - 
nonvar(X) , ! , 

solve_thawed(FrozenGoals,TmpFrozenGoals, 

PreviousConstraints .TmpConstraints) , 
solve (Goal .TmpFrozenGoals .NewFrozenGoals , 

TmpConstraints, NewConstraints) . 

convert ( ( ! ,X) , OldFrozenGoals .NewFrozenGoals , 

OldConstraints , NewConstraints , 

».>(call(!),NewX)) !, 

convert (X .OldFrozenGoals .NewFrozenGoals , 

OldConstraints , NewConstraints , NewX) . 
convert ( (merge .constraints (C) , X) , OldFrozenGoals .NewFrozenGoals , 
OldConstraints .NewConstraints , 

(append(01dConstraints .C.TmplConstraints) , 
solve_constraint(TmplConstraints ,Tmp2Constraints) , 
NewX 
)) !. 

convert (X , OldFrozenGoals .NewFrozenGoals , 

Tmp2Constraints .NewConstraints, NewX) . 
convert ( (write.constraints , X) , OldFrozenGoals .NewFrozenGoals , 
OldConstraints .NewConstraints , 

(write (’Debugging .. .’) .nl.writeList (OldConstraints) , 
NewX 

)) 

convert (X , OldFrozenGoals .NewFrozenGoals , 

OldConstraints .NewConstraints , NewX) . 
convert ( (XI , X) , OldFrozenGoals , NewFrozenGoals , 

OldConstraints .NewConstraints , 

(solve(Xl , OldFrozenGoals .FrozenGoals , 

OldConstraints.Constraints) , NewX)) 
nonvar(Xl) ,nonvar(X) , ! , 

convert (X .FrozenGoals .NewFrozenGoals .Constraints . 


13 



NewConstraints.NewX) . 
convert ( ! .FrozenGoals .FrozenGoals , 

Constraints , Constraints , ! ) : - ! . 
convert (true , FrozenGoals , FrozenGoals , 

Constraints ,NewConstraints , 
solve_constraint (Constraints, NewConstraints) 

) !. 

convert (write_constraints, FrozenGoals, FrozenGoals, 

Constraints , Constraints , 

(write ( ’Debugging . . . ’ ) ,nl,writeList (Constraints) ) 

) !. 

convert (merge_constraints (C) , FrozenGoals , FrozenGoals , 

Constraints .NewConstraints , 

(append(Constraints , C ,TmpConstraints) , 
solve _ constraint ( TmpConstr aint s , N ewCons tr aint s ) 

)) !. 

convert (X , OldFrozenGoals , N ewFrozenGoals , 

OldConstraints .NewConstraints , 
solve (X, OldFrozenGoals .NewFrozenGoals , 

OldConstraints .NewConstraints) 

) nonvar(X) , ! . 

solve_goal(Goal) 

convert (Goal , □ .NewFrozenGoals, 0 .NewConstraints.NewGoal) , 

NewGoal , 

write (’Unsolved Frozen Goals :\n’), 
write (NewFrozenGoals) ,nl, 
write ( ’Unsolved Constraints ;\n’ ) , 
writeList (NewConstraints) . 

The main call to the interpreter is through solve_goal. It starts by converting the 
user specified Goal into a proper format which IF /Prolog can understand (converting 
the call for merge_constraints to calling of the constraint solver) and executes it. 

The relation solve(Goal, ...)is true if Goal is true with respect to the program 
being interpreted. The interpreter can be read as follows. For the first clause 
of solve, the constant true is true. The solve^ fact states that the empty goal, 
represented in Prolog by atom true, is solved. The conjunction ’,’(Goall,Goal) is 
true if Goall is true and Goal is true. The next two clauses are used to interprete 
the freeze predicate. The predicate freeze is used to delay Goal on variable X in 
freeze(X,Goal). If Xis not instantiated, then Goalis frozen on the FrozenGoals Stack 
to be thawed later when X gets instantiated. K however, X is already instantiated, 
then Goal is solved directly. The next clause for solve shows that Goal is true if 
there is a clause Goal Tail such that Tail is true. This means, choose a clause 
from the program whose head umfies with the goal, and recursively solve the body 
of the clause. The final clause for solve states that if Goal is a predicate internally 
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defined by the interpreter on which the meta-interpreter is running, then allow the 
interpreter to execute it. 

This demonstrates that the meta-interpreter indeed refiects Prolog’s choices of 
implementing the abstract computation model of logic programming. The two 
choices are the selection of the leftmost goal to reduce, and sequential seaxch and 
backtracking for the nondeterministic choice of the clause to use to reduce the goal. 
The goal order of the body of the solve clause handling conjunctions guarantees 
that the leftmost goal in the conjunction is solved first. Sequential search and 
backtracking comes from Prolog’s behaviour in satisfying the clause goal. 

The call to clause in the fifth clause for predicate solve performs the unification 
with the heads of the clauses appearing in the program. It is also responsible for giv- 
ing different solutions on backtracking. Backtracking also occurs in the conjunctive 
rule reverting from Goal to Goall. 

The solve-thawed predicate is for solving the frozen goals. After every check of 
a clause, the frozen predicates are checked for possible execution. If the variable 
on which a goal is frozen has now been instantiated, then the goal is set up for 
execution. If the variable is not instantiated, then the goal is pushed back on to the 
FrozenGoals Stack. 

Simulating the behaviour of cut is a problem with a meta interpreter. The naive 
solution is to consider cut as a system predicate. Effectively, this means adding the 
clause : 

solve(!) :- !. 

This clause however does not have the required effect. The cut in the clause guar- 
antees commitment to the current solve clause rather than affecting the search tree 
of which the cut is a part. In other words, the scope of the cut is too local. The 
solution we have provided is to convert the right hand sides of clauses used, to calls, 
and executing them such that the cut takes place at the ancestor. 

The first clause of convert with (!,X) keeps the cut transparent by converting 
it to a call(!). The second clause of convert with (merge-constraints(C),X) is used 
to convert this merge_constraints call to calls for appending the current set of con- 
straints with the old set of constraints using append and for solving them with 
solve^constraint The third clause of convert with (write-constraints,X) is converted 
to calls to inform the user of the current set of constraints. The fourth clause is 
the conjunction (XI, X) which is converted to calls to the solve predicate. The 
goal / is transparently converted to a /. The goal true is converted to a call to 
solve-constraint since in the current implementation the constraints are solved at 
the ends of derivations. 


3.5 Invoking the constraint solvers 

The proper constraint solvers are called depending on the name of the solver spec- 
ified by the user. The default constraint solver used is for domain float, namely 
solve_float_equation. A part of the listing is shown below. 


15 



/* constraint. pro */ 

/* Procedure to solve the list of constraints ♦/ 
solve_constraint(A,C) 

actual_solve_constraint (A ,B) , 
continue_solve_constraint(B,C) . 
continue_solve_constraint(A,B) 
retract (constraint_changed) , ! , 
solve_constraint(A,B) . 
continue_solve_constraint(A,A) . 

assert.if .not .present (A) 
retract (A) .fail, 
as s ert . if .not .pres ent ( A ) : - 
asserta(A) . 

actual.solve.constraintCC] , □) . 
actual. solve.constraint ( 

C( [Type] .Solver ,SInl) I Sin] .NewSOut) !. 

S =. . [Solver. SInl, SOutl] . 

S. 

actual. solve. constraint (SIn.SOut) . 

cons2.constraint(Type. Solver. SOutl. SOut. NewSOut). 

'/, default float constraint solver 
actual.solve. constraint ( [SInl I Sin] .NewSOut) : - 
actual.solve. constraint ( 

[([float] .solve.float. equation. SInl) iSIn] .NewSOut) . 

cons2.constraint(.. .. □. SOut. SOut) !. 
cons2.constraint(ConstraintType. ConstraintSolver . 

SOutl. SOut. 

[([ConstraintType] .ConstraintSolver, SOutl) iSOut]) . 

actuaLsolve-constraint calls the solver with a single constraint at a time, one by 
one until all the constraints have been considered. If during actuaLsolve-constraint, 
any of the constraints are modified, as indicated by the constraints^changed flag, 
then continue-Solve.constraint again marks the complete set of constraints as ‘to 
be solved’, solve^constraint keeps calling actuaLsolve-constraint, until none of the 
constraints are modified. 


3.6 Using the meta- interpreter for CLP 

Consider the program in Figure 3.1 written for the meta-interpreter. The first two 
clauses represent Ohm’s law and KirchofF’s law; the next two define the sum of a list 
in the usual way using head and tail notation. This is followed by a small database 
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[metaclp] . '/, Load the CLP meta- interpreter 

ohmlaw(V,I,R) 

merge_constraints( [V=I*R] ) . 
kirchoff(L) 

sum(L,Zero) ,merge_constraints( [Zero=0.0] ) . 
sum( □ .Zero) : - merge.constraints ( [Zero=0 .0] ) . 
sumCCHiT] .N) 

merge_constraints ( [H+M=N] ) , sumCT.M) . 
availres(lO.O) . 
availr6s(14.0) . 
availres(27.0) . 
availres(60.0) . 
availresClOO .0) . 
availcell ( 10. 0) . 
availcell (20.0) . 
constr ainV ( V ) 

merge.constraintsC Cl4.5<V, V<16.25]) . 
goal solve_goal(( 
constrainV(V2) , 

availres(Rl) , availres (R2) , availcell(V) , 

ohmlaw ( VI , I 1 , R1 ) , ohml aw ( V2 , 12 , R2 ) , 

kirchoff([Il.-(I2)]) . 

kirchoff(C-(V). VI. V2]). 

write(’V=’) ,write(V) . 

writeC’. Rl=’) ,write(Rl) . 

writeC’. R2=’) ,write(R2) . 

writeC’, V2=’) .write (V2) . 

sum. of .products (V2 .NewV2) . 

writeC’ = ’ ) ,write(NewV2) .nl.fail 

)). 


Figure 3.1; Problem using Ohm’s Law and Kircholf’s Law 
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of resistors and cells. Finally we have the goal which calls solve.goal to staxt the 
meta-interpreter. The parameter to solve.goal consists of the representation of a 
simple circuit of two resistors (R1 and R2) connected in series with a ceU (V). It is 
required that the voltage over R2 should be between 14.5 and 16.5 volts. Thus the 
goal a^ks for the possible values of the components in this list. 

Each instance of a,b,c of Rl, R2, and V such that 14.5 <V2 < 16.25 gives rise 
to the problem ; Is the following solvable? 
yi/a- V2/6 = 0.0 
yi-f-V2 = c 

The meta interpreter computes the three sets of solutions: 

V=20.0. Rl=10.0, R2=27.0, V2=27.0 * 0.540541 = 14.5946 
V=20.0. Rl=14.0, R2=60.0. V2-60.0 * 0.27027 = 16.2162 
V=20.0. Rl=27.0, R2=100.0, V2*100.0 * 0.15748 = 15.748 

Note how the constraints are specified in the form of a list passed as a parameter 
to the predicate merge-Constraints in Figure 3.1. Also note that a special call to 
the predicate sum-of.products needs to be given to simplify the expression given by 
the solver. Further details regarding the requirement of this special predicate are 
given on page 54. In the definition of sum, the variable M is used by the constraint 
H + M — N which is defined only by the next term, sum(T,M). This would not 
be possible with most Prolog implementations if the constraint is specified directly 
because variables have to be instantiated before any expression containing them is 
evaluated. 
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Chapter 4 


Solving Problems on our 
system 

In this chapter we present formulas which describe our system and also give an 
idea of how the predicate freeze and the constraints solving techniques provided 
can be used for solving generate and test type of problems, and for geometrical 
theorem proving. For further examples demonstrating both the capability to delay 
constraints until they are consistent and the equation solving ability of the constraint 
solvers to find solutions, see Appendix F. 


4.1 Meaning of a program in our system 

A deducible fact represents a proposition that the programmer considers true. The 
set of deducible facts of a program is usually infinite. The execution of a program 
can be regarded as a search through this infinite database. This database cannot be 
stored in explicit form, but must be finitely represented from which all information 
in the database can be deduced. The aim of a program’s execution is to solve the 
following problem : Given a sequence of terms and a system of constraints, find the 
values of the variables that satisfy all the constraints and transform the sequence 
of terms into a sequence of deductions. 

The three formulas below describe our CLP system : 

1. (W, to h ...t„, S), 

2. SQ ... ^771 9 H' 

3. (W, Si ...Smh . . . tn, S U E U {so = to})- 

Formula 1 represents the state of the machine at any given moment, W the set of 
variables whose values we want to establish, to ... tn is a sequence we are trying to 
delete and S is a system of constraints that has to be satisfied. Formula 2 changes 
the state of the machine. If necessary, some variables have to be renamed. Formula 
3 is the new state of the machine after rule 2 has been applied. We start from an 
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installments.capitalC □ ,0.0). 
installments_capital( [I |X] ,C) 

•CY=1 .1*C-I}, installments_capital(X,Y) . 


Figure 4.1: Banking Calculation Problem 


initial state (where W is the set of variables that appear in the query) and then 
calculate all the states by applying the above procedure. Each time we arrive at a 
state where the sequence of terms is empty, we simplify the system of constraints 
with which it is associated and provide this as an answer. 

This is illustrated using the Banking Calculation Problem [24] listed in Fig- 
ure 4.1. In this example, the task is to calculate a series of successive installments 
that have to be made to repay an amount of money borrowed from a bank. As- 
sume a constant time period between installments and a 10 percent interest rate 
per period. 

The first rule expresses the fact that it is not necessary to pay an installment if 
the amount owed is 0.0. The second recursive rule states that a list of installments 
required to repay an amount C consists of an installment I plus the list of install- 
ments required to repay the amount C increased by 10 percent interest and reduced 
by installment I. 

This program can be used in different ways. The most spectacular way is to 
ask what three payments should be made to repay Rs 1000.0 such that the second 
payment is twice the value of the first, and the third payment is three times the 
value of the first. In other words, what value of I is required to have the sequence 
of installments [1,21,31]. The following query is all that needs to be specified by the 
user : 

goal installments_capital([I,2.0*I,3.0*I] ,1000.0) , 
write ("Answer: I=") ,write(I) ,nl. 

A trace of the program is as follows : 

({/}, instaIlments_capital([/,2 * J,3 * J],1000.0),{}). 

By applying the second rule of the program, we get : 

({/}, installments_capital(A',l.l *C - Newl), 

{installments_capital([I,2 * J,3 * J], 1000.0) = 
installments_capital([JV'eu;/ — X] ,<?)}). 

We obtain this by giving the variables in the rule all the possible values that satisfy 
the system. The particularized rules do not use variables or constraints and form 
the deductible facts of the program. This simphfies to : 

({/}, installments_capital(X,l.l *C - Newl), 

{Newl = I, X = [2*I,Z* i], 0=1000.0}). 
and then to : 

({/}4nstallments_capital([2 * 7,3 * i], 1100.0 — !),{}). 
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mortgage(P,Time,I,B,MP) 

•CTime=<1.0, B+HP = P*(1.0+I)}. 
mortgage(P,Time,I,B,MP) 

{1 .0<Time}, 

mortgage (P*(1.0+I)-MP, Time-1.0, I, B, MP) . 
goal 

Time = 5.0, 1=0.1, B=0.0, mortgage (P, Time, I, B, MP) , 
write(’P=’) ,writeCP) ,nl,writ6(’MP=’ ) ,write(MP) ,nl. 


Figure 4.2: Mortgage 


By applying the second rule and third rule again, we eventually obtain, 

({/},{}, {1331.0 - 6.41 *1 = 0.0}). 

Thus the sequence of terms has been transformed successively into a sequence of 
deductible facts by satisfying all the constraints. This leads to the final response 
of : 

{1 = 207.64}. 

Thus I = Rs 207.64. 

Our CLP system also has the potential to produce symbolic output as illustrated 
by the next example listed in Figure 4.2. The predicate mortgage is defined in 
terms of the principal (P), the duration (Time), the intertest rate (I), the monthly 
payments (MP), and the balance (B). The goal specifies values for the variables 
Time, I, and B, leaving the CLP system to determine the other two. 

The answer, P = 3.79079 *MP for goal expresses the linear relation that exists 
between principal amount ajid monthly payment. 

The practical realization of the three formulas enumerated in this section is 
considered in the following chapters. 


4.2 The generate-and-test technique 

Generate-and-test is a common technique in algorithm design and programming. It 
is easy to write logic programs that under the execution model of Prolog, imple- 
ment the generate-and-test technique. In generate-and-test, one process or routine 
generates the set of candidate solutions to the problem, and another process or rou- 
tine tests the candidates trying to find one, or all of the candidates which actually 
solve the problem. Typically, generate-and-test programs are easier to construct 
than programs that compute the solution directly, but they are also less efficient. A 
standard technique for optimizing generate and test programs is to try and “push” 
the tester inside the generator, as “deep” as possible. Ultimately, the tester is com- 
pletely intertwined with the generator, and only correct solutions are generated to 
begin with. 

Generate-and-test programs in Prolog typically have a conjunction of two goals. 
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mortgage(P,Time,I,B,MP) 

•CTime=<1.0, B+MP = P*(1.0+I)}. 
mortgagG(P,Time,I,B,MP) 

■Cl.O<Time}, 

mortgage (P*(1.0+I)-MP, Time-1.0, I, B, MP) . 
goal 

Time = 5.0, 1=0.1, B=0.0, mortgagG(P,TimG,I,B,MP) , 
write(’P=’) .writeCP) , nl, write (' MP=’ ) ,write(MP) ,nl. 


Figure 4.2: Mortgage 


By applying the second rule and third rule again, we eventually obtain, 

({/},{}, {1331.0 - 6.41 *1 = 0.0}). 

Thus the sequence of terms has been transformed successively into a sequence of 
deductible facts by satisfying all the constraints. This leads to the final response 
of : 

{7 = 207.64}. 

Thus I = Rs 207.64. 

Our CLP system also has the potential to produce symbolic output as illustrated 
by the next example listed in Figure 4.2. The predicate mortgage is defined in 
terms of the principal (P), the duration (Time), the intertest rate (I), the monthly 
payments (MP), and the balance (B). The goal specifies values for the variables 
Time, I, and B, leaving the CLP system to determine the other two. 

The answer, P = 3.79079 * MP for goal expresses the linear relation that exists 
between principal amount and monthly payment. 

The practical realization of the three formulas enumerated in this section is 
considered in the following chapters. 


4.2 The generate-and-test technique 

Generate-and-test is a common technique in algorithm design and programming. It 
is easy to write logic programs that under the execution model of Prolog, imple- 
ment the generate-and-test technique. In generate-and-test, one process or routine 
generates the set of candidate solutions to the problem, and another process or rou- 
tine tests the candidates trying to find one, or all of the candidates which actually 
solve the problem. Typically, generate-and-test programs axe easier to construct 
than programs that compute the solution directly, but they are also less efficient. A 
standard technique for optimizing generate and test programs is to try and “push” 
the tester inside the generator, as “deep” as possible. Ultimately, the tester is com- 
pletely intertwined with the generator, and only correct solutions are generated to 
begin with. 

Generate-and-test programs in Prolog typically have a conjunction of two goals. 
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sort(Xs,Ys) 

genlengthlistCXs.Ys) , 
ordered(Ys) .writeC’Ordered’) ,nl, 
permutationCXs.Ys) . 
permutation (Xs , [Z | Zs] ) : - 

sel6ct(Z,Xs,Ys) , permutation(Ys,Zs) . 
permutationC □ , □ ) . 
select (X. [XlXs] ,Xs). 

selectCX, [YlYs] , [YlZs]) select (X, Ys, Zs) . 

ordered ([X] ) . 

orderedCCX.YlYs]) 

freeze(X,freeze(Y,X=<Y)) ,ordered( [YlYs] ) . 
genlengthlist ([],□) : - ! . 
genlengthlist ( [_ | Rest] , [_ | VarRest] ) : - 
genlengthlist (Rest, VarRest) . 


Figure 4.3: Permutation Sort 

in which one acts as the generator and the other tests whether the solution is 
acceptable, as in the following clause : 

find(X) generate(X) .testCX) . 

When called with find(X), generate(X) succeeds returning some X, with which 
test(X) is called. If the test goal fails, execution backtracks to generate, which 
generates the next element X. This continues iteratively until the tester successfully 
finds a solution with the distinguishing property, or the generator exhausts alterna- 
tive solutions. Reference [31] shows a number of examples using this technique. 

4.2.1 Using a delay mechanism (freeze or dif) 

Consider the example “permutation sort”. The top level is as follows : 

sort(Xs,Ys) permutationCXs,Ys) ,ordered(Ys) . 

Abstractly, this program nondeterministically guesses the correct permutation via 
permutation(Xs, Ys), and ordered(Ys) checks that Ys is actually ordered. Permu- 
tation sort is a highly inefficient sorting algorithm, requiring time exponential in 
the size of the list to be sorted. The generator for permutation sort, permutation 
selects an arbitrary element and recursively permutes the rest of the list. The tester, 
ordered, verifies that the first two elements of the permutation axe in order, then 
recursively checks the rest. If however, the order of permutation and ordered is 
interchanged from the one shown above, then only the correctly ordered elements 
are selected. The freeze predicate as defined by Prolog-II is used to preorder the 
output list in the program shown in Figure 4.3. 
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queens (N,Qs) 

ranged, N, Ns, Qs),safe(Qs) ,permutation(Ns,Qs) . 

safeCCqlQs]) safe(Qs), notattack(Q,Qs) . 
safeCD) . 

notattack(X,Xs) notat'tack(X,l,Xs) . 

notattack(_,_, □) !. 

notattack(X,N, [YlYs] ) 

freeze (X, freeze (Y, X \== Y + N)), 
freezeCX, freeze(Y, X \“ Y - N)), 

N1 is N + 1, 
notattackCX, Nl, Ys) . 

permutationCXs, [Z|Zs]) 

select (Z,Xs,Ys) , permutation(Ys,Zs) . 
permutationC □ , □ ) . 

select (X.CXlXs] ,Xs). 

selectCX, [YlYs] , [YlZs]) select(X,Ys,Zs) . 

range(M.H,[M|Ns],C_|Temp]) 

H < N, Ml is M + 1, range (Ml, N, Ns, Temp) . 
range(N,M, [N] ,[_]). 


Figure 4.4: N Queens Problem 


The output produced by sort([l, 3, 5, 2, 7, 9, 0, 8, 6, 4],Z) is Z = [0, 1, 2, 3, 4, 
5, 6, 7, 8, 9]. 

Let us consider another problem, the N queens problem which requires the 
placement of N queens on an N-by-N rectangular board so that no two queens are 
on the same line : horizontal, vertical or diagonal. 

The program has been well studied in the recreational mathematics literature. 
There is no solution for N=2 and N=3. Given in Figure 4.4 is a generate-and-test 
program using the freeze predicate for generating only the necessary permutations. 

The relation queens(N,Qs) is true if Qs is a solution to the N Queens Problem. 
Solutions are specified as a permutation of the list of numbers 1 to N. The first 
element of the list is the row number to place the queen in the first column, the 
second element indicates the row number to place the queen in the second column, 
etc. 
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Tlie program behaves as follows. The predicate mnge creates a list Ns of the 
numbers 1 to N and an uninitialized list Qs of length N. The safe predicate sets up 
constraints which test the permutations as soon as they are generated by permuta- 
tion predicate. Thus each queen is checked as it is being placed. Since two queens 
are not placed on the same row or column, the predicate need only check whether 
two queens attack each other along a diagonal. Predicate safe is defined recursively. 
A list of queens is safe if the queens represented by the tail of the list are safe, 
and the queen represented by the head of the list does not attack any of the other 
queens. The definition of notattack( Q,Qs) is a neat encapsulation of the interaction 
of diagonals. A queen is on the same diagonal as a second queen N columns away 
if the second queen’s row number is N units greater than, or N units less than, the 
first queen’s row number. The diagonals are tested iteratively until the end of the 
board is reached. The second clause for no-attack may be rewritten using dif. 

The query queens(4,Qs), write(Qs), nl, fail, gives two solutions namely Qs = 
[2, 4, 1, 3] and Qs = [3, 1, 4, 2]. The query queens(8,Qs). gives the solution Qs=[l, 
5, 8, 6, 3, 7, 2, 4]. There are however 92 solutions for 8-queen problem which can 
easily be generated by giving the proper query. 

The main advantage of constrained terms and the coroutine mechanism is to 
apply tests as soon as possible. But the computation paradigm is still “generate- 
and-test” : an enumeration procedure is used to generate values and the constrai n ts 
are used in a “passive” way to test these values. Therefore the search space is 
reduced “a posteriori” after detecting failures due to inconsistent instantiation of 
variables. 


4.2.2 Using constraint solvers 

Intertwining generation and testing can also be done by adding the tests as con- 
straints [17] before the generation. Thus instead of generating the complete set of 
permutations, many of which have no chance of being solutions, only some of the 
permutations are generated. Refer to Appendix F.3, the Light Meals problem and 
to Appendix F.4, the Cryptarithmetic Puzzle for illustrating the use of constraints 
in this manner. 

Another way to use constraints is the “active” way which consists in reducing 
the search space in an “a priori” way by removing inconsistencies, i.e. combinations 
of values which cannot appear together in a solution. This approach requires the 
use of some advanced techniques like constraint propagation, consistency checking 
and sophisticated tree searching like lookahead procedures. Thus a programmer 
formulates the constraints of the problem at hand in a generate-and-test like man- 
ner, and the execution mechanism of the CLP-environment applies various efficient 
constraint satisfaction techniques to solve this set of constraints. Refer to [29] for 
further details on Finite Domain CLP. We have not implemented constraints in 
finite domains in the current system. 
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4.3 Geometrical Theorem Proving 

We consider the following theorem taken from [2] : 

Let ABCD he an arbitrary quadrangle. Refer to Figure 4 - 5 . Let E, F, G, and H be 
mid-points of edges AB, BC, CD, DA, respectively. Then the quadrangle EFGH is 
a parallelogram. 

To prove the theorem, this geometrical problem can be transformed to an alge- 
braic problem by introducing the Cartesian coordinate system. A midpoint (2:2 >2/2) 
of a segment (xi, yi)— (xs, y^) can be represented by equations X2 = (xi+X3)/2, 2/2 = 
(yi + ^3)72. The fact that segment (xi,yi) - (x2,yi) is paxallel with the segment 
{xs,yz) — ( 2 : 4 , 2 / 4 ) can be represented by an equation : 

(y 2 - yi)/(«2 - *1) = (^4 - 2/3)/(®4 - Xz). 

These equations axe represented as follows ; 

mid(Xl,yi,X2,Y2,X3,Y3) 

{2.0 * X2 = XI + X3, 2.0 * Y2 = Yl + Y3}. 
para(Xl,Yl,X2,Y2,X3,Y3,X4,Y4) 
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{(X1-X2) * (Y3-Y4) * (Y1 - Y2) * (X3 - X4)>. 

By evaluating the following query against the above program, the given theorem is 
proven. 

goal 

midCO.O, 0.0, X4, Y4, XI, Yl), 
midCXl, Yl, X5. Y5, X2, Y2) , 
mid(X2, Y2, X6, Y6, X3, 0.0), 
mid(X3, 0.0, X7, 0.0, 0.0, 0.0), 
para(X4, Y4, X5, Y5, X7, 0.0, X6, Y6) , 
para(X4, Y4, X7. 0.0, X5, Y5, X6, Y6) . 

The basic idea of this program and query is to certify that two pairs of segments, 
whose endpoints are constrained to be the midpoints of the original quadrilateral, 
are parallel. 
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Chapter 5 

Vienna Abstract Machine 


The Vienna Abstract Machine [23] is a Prolog machine developed at Technische 
Universitat Wien. An inference in YAM (in contrast to the standard implementation 
technique, the Warren Abstract Machine - WAM [32, 22]) is performed by unifying 
the goal and the head immediately instead of by passing arguments through a 
register interface. We are using the V AM^p [23] implementation since it is well 
suited for an intermediate code emulator. During an inference, VAM 2 P fetches one 
instruction from the goal code and one instruction from the head code and executes 
the combined instruction. VAM performs cheap shallow backtracking, needs less 
dereferencing and trailing and implements a faster cut. Comparison of VAM with 
WAM is given in Appendix B. 


5.1 Representation of clauses 

The representation of clauses in VAM intermediate code is very close to their syn- 
tactic representation. The three different kinds of codes used are : 

control codes Control Codes are used to embrace goals. A goal starts with c.goal 
< > and either ends with a c_call if another goal follows or ends with cJastcall if it 
is the last goal in a clause. c_cut is used for the cut choice points. 

head codes Head Codes are used to encode terms in the arguments of a clauses 
head. The arguments are translated into flat prefix code. The following head codes 
are used : 

h_nil, h-const, hJist, h-struct, h.void, h_fstvar, 
h_nxtvar, hJsttmp and h_nxttmp. 

goal codes Goal Codes encode terms in goals. The structure is the same as for 
head codes. The following goal codes are used : 
g_nil, g_const, gJist, g_struct, g-void, g-fstvar, 
g_nxtvar, gJfetuns and g_axtuns. 
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5.2 Memory model 

The representation of dynamic terms is based on structure copying. The VAM uses 
three stacks : 

1. The Environment Stack contains the stack frames which hold the local vari- 
ables and control information. It is either a determinate or a nondeterminate 
stack frame (choice point). 

2. Lists and structures are stored on the Copy Stack. 

3. Variable bindings are stored on the Trail. 

In the current implementation all this except backtracking in case of cuts is 
taken care of by Prolog itself. Thus these three stacks are neither specified nor used 
directly. Instead only a list of choice points is passed for backtracking. 

5.3 Specification of VAM 

The specification describes the process of unification and (determinate) control in 
detail. Backtracking aspects and cuts are not explicitly covered. Backtracking in 
absence of cuts is implicit in the specification. 

5.3.1 An Abstract Interpreter for VAM 

The interpreter consists of a tail recursive predicate vam_prove/3 which holds the 
interpreter state consisting of the remaining head goals, the list of remaining goal 
codes, a continuation stack for nested calls. ‘vam_prove/3’ has the form : 

*/, vam_prove(HeadCode jGoalCode .Stack) 

y. vam_prove/3 : Check and execute the instructons at the two 
*/, instruction pointers after combining them. 

vam_prove( [c.nogoal] , [c.lastcall] , □ ) . 
vam_prove( [HlHs] , [G|Gs] ,St) 

unification(H+G,Hs,NHs,Gs,NGs) , 
vam_prove(NHs,NGs,St) . 
vam.proveC [HlHs] , [G|Gs] ,St) 

r esolut ion (H+G , Hs , Gs , NGs , St , NSt , N extPred) , 
vam_clause( [NextPredlNHs] ) , 
vam_prove(NHs,NGs,NSt) . 

The details of cuts have been omitted here for simplification. This has however been 
explained in a later section on extensions of VAM. The process of interpretation 
consists of unification and resolution. These steps correspond to the different kinds 
of codes. The state transitions are specified by facts in order to emphasise which 
states are changed. Before trying to prove these facts, the interpreter takes the first 
elements of both lists (head ajid goal code) and combines them in order to pass 
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them to the facts. The effective instructions HeadCode + GoalCode are derived by 
generating all valid combinations of head and goal codes. 

5.3.2 Unification 

An attempt is made to unify corresponding arguments of head and goal; the re- 
maining codes are passed back to vam_prove/3. TJnification/5 has the form : 

unification(Instruction, Headsin, HeadsOut, Goalsin, GoalsOut) 
where Instruction is Head -(- Goal. In the actual implementation, a value called 
Unificationindex is used for Head -f Goal as shown in vam_prove/7. Combinations 
such as h^truct -1- g^const are not stated; they simply fail. Unification/5 only 
changes the head and goal code lists. Arbitrarily nested structures occuring in the 
head and the goal need neither a push down stack nor a counter to unify their 
arguments since the functors F/A do not insert their arity into vam_prove/3’s state. 
Some of the combinations axe illustrated below : 

*/, unif icationClnstruction, Headsin, HeadsOut, Goalsin, GoalsOut) 

'/, unification/5 : Unify corresponding arguments in Headsin and 
'I, Goalsin depending on Instruction and return the 

y, remaining code via HeadsOut and GoalsOut. 

unif ication(void+void,Hs,Hs,Gs,Gs) . 
unif ication(void+fstvar,Hs,Hs, Cvar(_) iGs] ,Gs) . 

unif icationCfstvar+fstvar, Cvar(V) iHs] ,Hs, Cvar(V) |Gs] ,Gs) . 
unif icationCfstvar+nxtvar, [var(V) iHs] ,Hs, [var(V) iGs] ,Gs) . 

unif ication(constant+f stvar , 

[ClHs] ,NewHs, Cvar(V) |Gs] ,NewGs) 
nonvar(V), !, V = [VllVRem], 

unification(constant+Vl, [ClHs] ,NewHs,VRem,TempGs) , 
append(TempGs,Gs,NewGs) . 
unif ication(constant+f stvax , 

[C 1 Hs] , Hs , [var ( [constant , C] ) I Gs] , Gs ) . 

unif icationCconstant+constant , 

Cconst(Const) IHs] ,Hs, [const(Const) |Gs] ,Gs) . 

unif icat ion ( struct+void , Hs , NHs , Gs , Gs ) 
peu:se_dl(_, [struct I Hs] ,NHs). 

unif ication(struct+nxtvar,Hs, NHs, [var(V) iGs] ,NewGs) 
nonvar(V) , ! , ,append(V,Gs,TempV) ,TempV=[Vl|V2] , 
unif ication_index(struct ,V1 ,UIndex) , 
imif ication (Ulndex , Hs , NHs , V2 , N ewGs ) . 
unif ication(struct+nxtvar,Hs, NHs, [var(V) |Gs] ,Gs) 
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parse.dlCV, [struct iHs] ,NHs) . 
unificationCstruct+struct.Hs.Hs.Gs.Gs) . 

“Parse.dl” has the form : 

parse_dl(Variable, Symbolsin, RemainingSymbols) 

The function of ‘parse_dl/3’ is to unify ‘Variable’ with the first structure from ‘Sym- 
bolsin’ and return the remaining symbols in ‘RemainingSymbols’. 

5.3.3 Resolution (Goal Selection) 

A clause of NPred meaning NextPredicate is selected by the interpreter with the 
database predicate vam_clause/l. If a fact in the head was proved and if the body 
contains another subgoal (cjnogoal -t- cjcall), the new goal is selected. The stack 
is not affected at all. If the head unifies and the goal was the last in the caller’s 
clause (c-goal + cJastcall), the head code wiU become the new goal code. Again the 
stack is not altered (last call optimization). If the head unifies and there is another 
goal in the caller’s clause (c.goal -t- c-call), then the continuation is pushed into the 
stack, the head code becomes the new goal code and the interpreter switches to the 
new clause’s head. The stack needs to be popped if a fact unifies and if the goal 
is the last in the caller’s clause {cjnogoal -1- cJastcall). Execution proceeds with 
the popped continuation. If the stack is empty, the interpreter halts successfully. 
Resolution/7 has the form : 

y, resolutionCHead, Goal, Heads, Goalsin, GoalsOut, 
y, Stackin, StackOut, BTOPIn, BTOPOut, NextPred) 

y, resolution/5: VAM_Goal selection 

resolution(c_nogoal,c_call, □ , [c_goal,c_cut |Gs] ,Gs, 

St,St,L,BT0PlBT],[BT0P|BT],functor(’!’,0)) !, 
newcutbacktrack(BTOP) . 
resolution(c_nogoal,c_call, n . 

[c_goal,v(4) ,fimctor(F,A) iGs] ,Gs, 

St,St,[_|BT] ,BT,functor(F,A)) !. 

resolut ion (c_no goal, c_call , □ , 

[c_goal,v(3) ,const(atoia(F)) iGs] ,Gs, 

St,St, [_|BT] ,BT,functor(F,0)) !. 

resolution(c_goal,c_lastcall, [c_cut iHs] , □ ,Hs, 

St,St,[BTl,.|BT3,[BTl|BT],functor(’!’,0)) !, 
newcutbacktrack(BTl) . 
resolution(c_goal , c.lastcall , 

[v(4) ,functor(F,A) IHs] , □ ,Hs, 
St,St,CBTl,_|BT],CBTl|BT],functor(F,A)) !. 

resolut ion(c_goal,c_lastcall, 

Cv(3) .const (atom(F)) IHs] , □ ,Hs, 
St,St,[BTl,.|BT],[BTllBT].functor(F,0)) !. 
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resolution(c_goal,c_call, [c.cutiHs] ,Gs,Hs, 

St,CGs|St].[BT0P|BT].[BT0P|BT],functor(’!'.0)) !. 
newcutbacktrack(BTOP) . 

resolutioii(c_goal,c_call, CvC4) ,functor(F,A) iHs] ,Gs,Hs, 

St.CGsiSt] .BT.BT, functor (F, A)) !. 

resolution(c_goal,c_call, [v(3) , const (atom(F)) iHs] ,Gs,Hs, 

St.CGsiSt] ,BT,BT,functor(F,0)) !. 

resolution(c^nogoal,c_lastcall, □ , □ ,Gs, 

CCc_goal,c_cut |Gs] 1st] ,St, 
C-,_,BTOP|BT],CBTOP|BT].functor(»!’,0)) !, 
newcutbacktrack(BTOP) . 
resolution(c_nogoal,c_lastcall, □ , □ ,Gs, 

CCc_goal,v(4) ,functorCF,A) |Gs] |St] ,St, 
L._lBT],BT,functor(F,A)) !. 

resolution(c_nogoal,c_lastcall, □ , □ .Gs, 

C[c_goal,v(3) , const (atom(F)) iGs] |St] ,St, 

[_,_1BT] ,BT,functor(F,0)) !. 

The ‘newcutbacktrack’ call marks all choice points from the one stated to the cur- 
rent one as unbacktrackable. This disallows the choice points from activating their 
choices from the point at which the requisite ‘newgetbacktrack’ call was made when 
backtracking takes place. 
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Chapter 6 


Structure Independent 
Inference Engine 

6.1 Introduction 

The Vienna Abstract Machine has been naodified and extended to handle constraints 
and it forms the underlying abstract machine for our inference engine. While the 
Constraint Solver only answers the satisfiability questions, the Inference Engine 
uses this capability to direct the collection of constraints. The inference engine thus 
provides a control mechanism and effectively executes derivations. Because of the 
inclusion of unification within the inference engine, the CLP system engine imple- 
ments almost complete Prolog. The details of the internally provided predicates 
are given in Appendix A. Programs may thus be written in normal Prolog form. 
For the programs to differentiate between programmed predicates and constraint 
relation symbols, the constraints must be surrounded by braces as in Prolog-Ill. 
Consider an example taken from [19], 

zmult(c(Rl,Il),c(R2,I2),c(R3,I3)) 

{ [float , [R3=R1*R2-I 1*12 , I3=R1*I2+R2*I 1] ] } . 

This single rule program models the relationship between two complex numbers 
and their products, where each complex number, X-f lY, is represented as c(X,Y). 
The above rule thus means that multiplication of a complex number c(Rl,Il) and 
c(R2,I2) equals c(R3,I3). The two equations in braces in the body of the above 
rule are constraints, ‘float’ specifies that the domain of these constrmnts is of type 
float. Other details of the constraint solver could be specified here before the list of 
constraints is specified in a list. The goal : 

zmult(c(R,I) ,c(10. 0,50.0) ,c(20. 0,50.0)) 

entails the solution of the simultaneous equations : 

20.0 = R * 10.0 - I * 50.0 

50.0 * R * 50.0 + 10.0 * I 
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giving the result R = 1.038461 and I = -0.192307. An under-specified goal will 
result in a symbolic answer. 

The same operators may be used both for unification as well as in constraints, the 
interface takes care of correct transmission of grounded terms between the constraint 
solver and the inference engine. In the above example, the equality symbol in the 
constraints indicates that it is an equality constraint and not the equal of Prolog 
which means unification. The constraints themselves may be specified in prefix form 
as in Prolog to make the specification structure independent or in infix form. For 
the latter, the “op” predicate will specify the precedence and arity (unary/ binary) 
of the operators used in the constraints as well as in normal Prolog. Currently the 
“op” predicate has not been implemented. Instead precedences for the common 
arithmetic operators axe hardcoded. 

6.2 Instruction set extensions 

Since the constraint solvers wiU need a variety of domains, different types of con- 
stants like atom, str, float, int have been allowed. For this purpose, the instruction 
“constant” has been modified. The unification instructions have also been extended 
to handle the unification of these constants. 

In the current implementation, new types of Domains like molecules [30], chem- 
ical graphs [3], or finite domains [29], etc. have to be specified as prolog terms 
or using the basic domain provided by the system. They cannot be specified and 
viewed in their natural form. This requires an extension of the instruction set and 
the unification instructions along with facilities for specification and a proper display 
of objects in these new domains. 


6.3 Extensions to Model 

To allow freezing of a goal and handling of constraints, three extra parameters 
have been added to the YAM interpreter - FrozenGoals, Constraints and the Dic- 
tionary. The goals which have been frozen because some variable is unbound are 
stored on the FrozenGoals Stack. As soon as a frozen variable gets bound, all goals 
waiting on that variable are popped from the FrozenGoals Stack one by one and 
executed. The constraints which are to be passed to the constraint solver are stored 
on the constraints stack. The variables used by the constraints are stored in the 
Dictionary with their corresponding counter-parts in the solvers. The predicate 
thawed_vam_prove/8 is used to activate the unfrozen goals. The new vam_prove/7 
and thawed_vam_prove/8 axe shown below : 

•/. vain_prove (Heads, Goals, St, BTOPList, FrozenGoals, 

•/, Constraints, Dictionary) 

•/, vam_prove/7 : Abstract interpreter 

vani_prove( Cc_nogoall , [c_lastcall] , D ,_, FrozenGoals , 

Constraints, Dictionary) 
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write (’Frozen Goals:’), 

user_understandable_write(FrozenGoals .Dictionary) ,nl, 
write ( ’ Constraints : ’ ) , 

user_understandabl6_write (Constraints .Dictionary) .nl. ! . 
ass ign_ constraint .values (Dictionary) . 
vain_prove( [HlHs] , [GlGs] .St.BTOPList.FrozenGoals. 

Constraints .Dictionary) 
write_if_debug(’Head: ’ ,H. ’ , Goal: ’ .G) . 
unif ication_index(H.G.UIndex) . 
unification(UIndex.Hs.NHs.Gs,NGs) . ! , 

vam.prove (NHs , NGs . St . BTOPList . FrozenGoals . Constraints . 
Dictionary) . 

vam.prove ( [H | Hs] . Gs . St . BTOP , FrozenGoals , 

Constraints. Dictionary) :- 

check_and_solve_constraint (H .Constraints . NewConstraints . 

Dictionary. NewDictionary) , 
thawed_vaiii_prove( [H iHs] .Gs. St. BTOP. □ .FrozenGoals. 

NewConstraints, NewDictionary) . 

thawed_vam_prove( [H 1 Hs] . [G I Gs] ,St .BTOP . 

UnsolvedFrozenGoals . □ .Constraints .Dictionary) : - 
resolution(H.G.Hs.Gs.NGs,St.NSt.BTOP.NBTOP.NPred). ! . 
write_if_debug( ’Solving * .NPred) . 

solve_predicate(NGs .NSt .NBTOP. NPred, UnsolvedFrozenGoals , 
Constraints, Dictionary) . 
thawed.vam.prove (Hs , Gs , St , BTOP , 

UnsolvedFrozenGoals, [[X I Goal] | FrozenGoals] , 
Constraints, Dictionary) :- 
var(X) , ! , 

append (UnsolvedFrozenGoals, [[XlGoal]] , 
NewUnsolvedFrozenGoals) , 
thawed_vam_prove(Hs ,Gs ,St .BTOP , 

NewUnsolvedFrozenGoals .FrozenGoals , 

Constraints .Dictionary) . 
thawed_vam_prove(Hs ,Gs ,St .BTOP , 

UnsolvedFrozenGoals , [C_ I Goal] iFrozenGoals] , 
Constraints, Dictionary) :- 
convert _to_call (Goal, NVar) , 
do_proper_append(Hs,NVar,NewHs) , 
thawed.vam_prove(NewHs ,Gs ,St .BTOP , 

UnsolvedFrozenGoals .FrozenGoals , 

Constraints .Dictionary) . 

do_proper_append( Cc-D-Ogoal] .TempHs.NewHs) :■ 
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appendC [c.goal iTempHs] , [c.lastcall] ,HewHs) . 
do_proper_append( [c.goal iRest] .TempHs ,NewHs) : - 

appendC Cc_goal I TempHs] , [c_call,c_goal iRest] ,NewHs) . 

Examples of the VAM code which is executed by the above routines are given 
in Appendix E. 
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Chapter 7 

Compilation 


In the current implementation, the user queries and the clauses in a user program 
are compiled separately. Each compiler which is written in Prolog and C (LEX and 
YACC) respectively is explained below. 

7.1 Compiler in Prolog 

The compiler for compiling user queries is implemented in Prolog. For this we have 
used the Operator Precedence Parsing [1]. The form of the compiler is : 

compileCCharacters.VAHCode) 

tokenizeCCharacters, Tokens) , 
parse (Tokens , IntermediateCode) , 
encodeClntemediateCode.VAMCode) . 

The scanner breaks a STRING up into a Hst of tokens of the foUowing kinds: 

TOK = Ibrack; rbrack; [ ] 

Ipar; rpar; ( ) 

Icurly; rcurly; { } 

var (STRING) ; X. This, _ok 

atom(STRING) ; hello . : - , : : : fail 

int (INTEGER); 123, -456 

real (REAL); 3.50e-2, 5.79 

str(STRING); "This is a STRING" 

char (CHAR); 

comma; > 

bar; I 

dot 

k symbol is either a name starting with a lowercase letter, or a sequence of following 
haracters: 
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<>?«#$& 


+ - * / = ‘ : . \ - 

The associativity and precedences defined for operators are : 

op_db(1200,xfx,(' op_db(1200,fy, ( ’ . 
op_db(1100.xfy, ’ ; . op.dbClOOO.xfy . ’ , . 

op_db(900,fy, ’not’) . 

op.db (700 , xf X , ’ = ’ ) . op.db (700 , xf X , ’ \= ’ ) . 

op_db (700 , xf X , ’ is ’ ) . op.db (700 , xfx . 

op.db (700 , xfx . op.db (700 , xf x , ’ > ’ ) . 

op.db (700 , xfx ,’>=’) . op.db (700 , xfx . 

op_db(700,xfx,’\==’) . op.db (700. xfx,’ = . . ’) . 

op.db (500 , yf X , ’ + ’ ) . op.db (500 , fx . 

op_db(500,yfx,’-’). op.db (500, f x, ’-’) . 

op.db (400 , yf X , ’ * ’ ) . op.db (400 . yf x , ’ / ’ ) . 

op.db (300, xfx, ’mod’) . 

Clauses could also be compiled using the above compiler as illustrated below. Con- 
sider the program for append : 

append( □ .Rest .Rest) !. 
append ([Chi Rest 1] ,Rest2, [ChlNewRest]) 
append(Restl,Rest2,NewRest) . 

The output for the text consisting of the above append program is : 

[t(atom(append) ,0) ,t(lpar,6) ,t(lbrack,7) ,t(rbrack,8) , 
t (comma, 9) ,t(var(Rest) ,10) ,t (comma, 14) ,t(var(Rest) ,15) , 
t(rpar,19) ,t(atom(( :-)) ,21) ,t(atom(! ) ,24) ,t(dot ,25) , 
t(atom(append) ,27) ,t(lpar,33) ,t(lbrack,34) ,t(var(Ch) ,35) , 
t(bax,37) ,t(var(Restl) ,38) ,t(rbrack,43) ,t(comma,44) , 
t(var(Rest2) ,45) ,t(comma,50) ,t(lbrack,51) ,t(vax(Ch) ,52) , 
t(baar,54) ,t(var(NewRest) ,55) ,t(rbrack,62) ,t(rpar,63) , 
t(atom((:-)) ,65) ,t(atom(append) ,71) ,t(lpar,77) , 
t(var(Restl) ,78) ,t(comma,83) ,t(var(Rest2) ,84) , 
t(comma,89) ,t(var(NewRest) ,90) ,t(rpar,97) ,t(dot,98) 

] 

The above scajined output when given to the parser, produces intermediate code as 
given below. 

For first clause of append : 

cmp((:-) , [cmp(append, [nill,var(Rest) ,var(Rest)]) ,atom(!)]) 

For second clause of append : 

cmp ((:-), [cmp ( append , [listpars er ( var ( ’ Ch’ ) , var ( ’ Rest 1 ’ ) ) , 
var(’Rest2’) ,listparser(var(’Ch’) ,var(’NewRest’))]) , 
cmp(append, [v 2 u:(’Restl’) ,var(’Rest2’) ,var(’NewRest’)])]) 
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Target program 

Figure 7.1: Phases of the compiler 
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The code generated for clauses is as follows : 

For the first append clause we have : 

VAMCode: 

[v(4) .functor (append, 3) ,v(3) , const (nill) ,v(l) , 
temporaryvar ( ’Rest ’ ) , v(2) .temporaryvar ( ’Rest ’ ) , 
c_goal , c_cut , c_lastcall 
]. 

Variables : [’Rest’] 

For the second append clause, the code generated is : 

VAMCode: 

[v(4) .functor (append, 3) ,v(5) ,v(l) ,temporaryvar(’Ch’) , 
v(l) ,temporaryvar(’Resti’) ,v(l) ,temporaryvar(’Rest2’) , 
v(5) ,v(2) ,temporaryvar(’Ch’) ,v(l) ,teinporaryvar(’NewRest’) , 
c_goal,v(4) .functor (append, 3) ,v(2) ,temporaryveir(’Restl’) , 
v(2) ,tempor«o:yvar( ’Rest2’ ) ,v(2) ,temporaryvar( ’NewRest ’ ) , 
c.lastcall 
]. 

Vaoriables : [’NewResf , ’Rest2’ , ’Restl’ , ’Ch’] 

As a general parsing technique, Operator Precedence Parsing has a number of dis- 
advantages. It is hard to handle tokens like the minus sign which has two different 
precedences depending on whether it is unary or binary. Worse, since the relation- 
ship between a grammer for the language being parsed and the operator precedence 
parser itself is tenuous, one cannot always be sure the parser accepts exactly the 
desired langauge. 

7.2 Compiler in C (LEX and YACC) 

In the current implementation clauses are compiled using the compiler written in C 
(LEX and YACC). This is useful for large programs where code can be produced 
and stored in intermediate form which can be directly loaded by the simulator. 
The phases involved in the compiler have been shown in Figure 7.1. Note that 
optimization phase has not been implemented. The complete grammer used for 
YACC is shown in Appendix G. 

The VAM-code for a program using constraints, namely the installments capital 
problem [9, 10] is shown in Appendix E.l and a section of the code for Example 13 
in Appendix C.9 that uses freeze [5] in Appendix E.2. 
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Chapter 8 

Solvers 


The real/float solvers currently implemented delay consideration of any nonlinear 
arithmetic constraints and linear inequalities. These constraints are assumed to be 
satisfiable until they become linear at some later time in a computation (this may 
happen when variables contained in a non-linear constraint or all variables in linear 
inequalities become ground), at which stage it will be considered for satisfiability. 
Thus it represents a compromise between generality and efficiency. It restricts 
consideration to a class of constraints which can be solved efficiently. However, 
by relaxing the satisfiability condition for such constraints rather than disallowing 
them altogether, the solver admits an important additional class of programs. 

Linear arithmetic constraints (equalities) are maintained in solved form. As 
each linear constraint is added, it is checked for satisfiability with the previous 
constraints (already in solved form). If the system is satisfiable, the new constraint 
is incorporated to generate a new solved form. A delayed constraint is added to the 
solved form when a sufficient number of its variables have been determined to make 
it linear. For example, 

hypCX,Y,powa*X + Y*Y, 0.5)). 

available (X.Y) {[real.K = Y]]}. 

goal {[real.CX + Y = 10.0, Z =< 8]]}, 
hyp(X,Y,Z), available (X.Y). 

The execution proceeds by collecting the two linear constraints, X — Y = 10.0, and 
Z =< 8. Next, the matching of the goal atom hyp(X,Y,Z) and the head of the 
rule hyp(X,Y,pow(X*X-|-Y*Y,0.5)) gives Z = pow(X*X-l-Y*Y,0.5). This constraint 
is delayed since it is not linear. The next constraint collected is X = Y, and this 
together with X + Y = 10.0, determine the values X = 5.0 and Y = 5.0. Now the 
ddayed constraint is used and Z = pow(5*5 -f- 5*5, 0.5) = 7.07 is added to the 
linear constraints. Since the linear constraints are satisfiable, the goal succeeds. 

We classify the solvers basically into two types - the black-box solvers and the 
incremental solvers. 
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8.1 Black Box Solvers 

A black-box solver is assumed to take in a system of constraints and return a 
simplified system of equivalent constraints. If the system of constraints is satishable, 
a ‘true’ status is returned. If the set of constraints is not satisfiable, then the solver 
returns ‘fail’ indicating that the inference engine should backtrack. An ‘error’ status 
is returned in case any error occurs in the interpretation of constraints or in case 
of communication errors. In this type of solver, each time a constraint is added or 
any of the constraint variables are unified with a term by the inference engine the 
solver is called with the whole set of collected constraints. Also, before the call the 
current state of the constraints has to be stored. 

8.2 Incremental solvers 

In the case of incremental solvers a single constraint is added to the set of constraints 
already stored at the constraint solver. The incremental solvers may or may not 
themselves backtrack. 

• In the case of incremental solvers, which do not provide backtracking to the 
earlier state of the solver in case of failure, storing of -the current state is 
imperative before a constraint is given to the solver so that backtracking can 
be simulated by initializing the solver and then sending the current state to 
the solver. 

• If the solver can backtrack, then a specific call must be given to the solver by 
the inference engine when we want it to backtrack because of some condition 
external to the solver. However, if the addition of the current constraint makes 
the system inconsistent, then the solver itself backtracks to its earlier state 
and returns a status ‘fjail’ to the Prolog Inference Engine allowing the inference 
engine to take proper action. In this case, no backtrack call is given to the 
solver, since it has already backtracked. 

Special care has been taken in our implementation to send backtrack calls even 
in case of cuts. Thus if a cut is present after a set of constraints was satisfied, 
and a failure later does not allow the state to backtrack to the earlier set of 
constraints (because of the cut), stiU proper backtrack calls will be sent to the 
incremental solver, ignoring the cut, so that synchronization is maintained 
between the inference engine and the incremental solver. Refer to Appendix 
D.4 for further details with the help of examples. 

In incremental solvers, in contrast to the Black Box solvers, the full set of constraints 
need not be given to the constraint solver, instead only the latest constraint is added 
to the set of constraints already stored by the solver. This minimizes the overhead 
of communication between the solver and the inference engine. However, no values 
are directly returned. Only consistency is checked for. Thus whenever any outputs 
are desired, a special ‘output’ call needs to be given to the solver with the variables 
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names for which values are wanted. Thus these calls incur an extra cost over the 
black box solvers. 


8.3 Alternative Solutions 

It is possible that the solvers may return multiple solutions. However this has not 
been currently implemented. The additional work that will be need to be done is 
to store the set of returned possibilities in the form of choice points. Each of the 
alternatives can be tried out later one by one as required once the inference engine 
has the control. 

If the incremental solvers have multiple solutions, then the other possibility is 
that the solver will go through one set of solutions, but a backtrack call will allow 
the solver to try out the other possibilities automatically. This case has also not 
been implemented in this version. 


8.4 Using pre-existing and custom built solvers 

Many pre-existing solvers exist for specific domains. With a view to accomodate and 
take advantage of these pre-existing solvers (example Mathematica [33], REDUCE 
[14]), a very general interface has been provided between the structure independent 
engine and the constraint solvers. Facilities have also been provided to take ad- 
vantage of incremental custom-built solvers. The solvers may be either on the host 
machine itself running the inference engine or on any other machine which can be 
accessed over the network. In the former case, the solver may be written directly 
by the user as an user program or it may be an independent solver attached as a 
module through the interface. In the latter case, currently ‘rpc’ (the remote proce- 
dure calls) is being used as the major method for communication. If the file system 
being used is common to the host machine and a solver, then the ‘sameJs’ method 
may also be used for communication. The technique of interfacing solvers to the 
Inference Engine has been elaborated in the next Chapter. 

8.5 Invocation points for solvers 

The CLP scheme specifies that the collected constraint set at each step must be 
satisfiable. However we have relaxed this condition and in the current implementa- 
tion the solver is being automatically called only at the ends of derivations. If this 
becomes expensive, then solver_off/0, solver_on/0, solvermow/0 can be used. Thus 
the user can place satisfiabiUty checks at key points in the program. Solvers for very 
complex domains may take a long time to solve even a smaU problem. Incorporating 
such solvers into CLP systems is impractical unless we can turn the solver off. 

• solver.off sto^s the automatic invocation of the constraint solver. 
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• solver-on restarts the automatic invocation of the constraint solver at ends of 
derivations. 

• solver-now invokes the constraint solver with the currently accumulated set 
of constraints right away. This is required to invoke the solver if automatic 
invocation has been put off. 

Thus these three routines help in maintaining complete control over the invocation 
of the required constraint solver. 
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Chapter 9 

Constraint-Solver Server 


The interconnection of computers serving as a Constraint-Solver Server supporting 
our constraint logic programming system is described below. A computer on which 
the inference engine is running, makes available a set of constraints to other comput- 
ers where constraint solvers are present, over a network shown as Communication 
interface in Figure 9.1. 

• When a request occurs from one computer, which is called the client, it con- 
verts the constraints from the Inference Engine format to an Intermediate 
format, using a Filter and transmits them to another computer, which is 
called the server. The Inference Engine, the Interface and the Filteri_E. 
are all present on the client itself as shown in Figure 9.1. 

• A Filter on a server machine converts the constraints from the intermediate 
form to the constrant solver form and passes the constraints to the constraint 
solver for evaluation. A number of servers containing a Filterc.s. and a con- 
straint solver are shown in Figure 9.1. 

• The constraint solver evaluates the constraints and returns the results (if any) 
to the client, again making the necessary transformation to the intermediate 
format for transmission over the network. 

• The results in the intermediate language are converted to Prolog terms and 
VAM form for use by the inference engine. 

Although, only a single solver is shown at each client, actually a number of solvers 
may be present along with their independent filters at each server. Solvers could 
be present on the client also, in which case requests need not be made over the 
network. The connection of such a solver is shown in Figure 9.1. Also note that the 
communication interface is not necessarily ‘rpc’, but could be any other method by 
which the inference engine and solver can interact, e.g. via files in case of Same file 
system. 

Multiple solvers can be interfaced. The user only needs to specify the domain 
over which the constraints are based in his application. The system has to be 
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XJonstrdih^ ~Sorv~er~ Server 
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Figure 9.1: A diagram of a modular CLP system whidi contains the Prolog-like 
inference engine, a number of constraint solvers distributed over the network, and 
the Constraint- Solver Server constituting the interface and filter on the client side 
and a number of filters connected to their respective constraint solvers at the servers. 
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detailed through the advice database about the available constraint solvers. The 
advice database is maintained by the system administrator. This allows the interface 
to select the proper constraint solver for invocation. 


9.1 Advice Database 

The advice database has been implemented as facts in Prolog which specify the 
details of different kinds of solvers available over the network. Each fact has the fol- 
lowing fields : DomainOfSolver, Strategy, Filter, TypeOfSolver, SolverName, Oth- 
er Details 

The first field is the DomainOfSolver. This could be any one of the domains 
selected from amongst float, char, string, list and int which are the basic domains 
currently provided by the inference engine. These domains could be used by the 
solver to solve constraints over other complex domains. See the example on multi- 
plication of complex numbers in the Introduction Section of Chapter 6. 

The SolverName is the name by which the Solver is referred to on the machine 
on which it is present. There could be a number of different types of solvers for the 
same domain residing on the same machine but having different names. 

The RemoteMachineName is the name by which the remote machine is refer- 
enced. This name is required to make contact with the machine on which the desired 
solver is present. The name ‘self’ is used to indicate that the client and the server 
machines are one and the same. 

The Strategy indicates the way the communication between the interface and the 
constraint solver is implemented. It could be either the RPC (Remote Procedure 
Call), or qprolog (the way Quintus Prolog allows invocation of a copy on another 
machine), or through files if the file system is shared between multiple machines or 
any other way the operating system might provide. 

The Filter specifies the form in which the text is transmitted over the network 
from the client side. In the current implementation all constraints are transmitted 
in text form. Thus the constrants have to be converted from the VAM instructions 
to text-atoms with the help of a filter on the client side before transmission. For 
efficiency, the filter could be bypassed completely if the client and server machines 
are binary compatible. In this case the structures may be passed directly. 

The TypeOfSolver field indicates whether the solver is a black-box solver, or an 
incremental one. This field is used to check the necessity to store the current set of 
constraints on the constraints stack. Also control of backtracking is done with the 
use of this field. This issue is dealt with in a later section. Examples of programs 
using black-box and incremental solvers are given in Appendix D. 

The OtherDetails field contains rest of the details not indicated above specific to 
the communication strategy used. For usage of remote procedure calls, it contains 
the program number, version number, time-out etc. For same file system it contains 
the file number and time out. Any comments can be included in this field. 
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9.2 Interface 

The CLP implementer can choose the most efficient internal representation for the 
constraint set, and is allowed to implement and interface the most suitable and 
efficient incremental constraint solving techniques. The interface determines the 
details for the specified domain from the Advice Database. The finding out of these 
details can be overridden if the user himself specifies the details completely. The 
constraints specified by the user in his application are converted to the following 
form : 

merge.constraints ( [[Details , Constraint.!] , 

• • • > 

[Details , Constraint _nm] ] ) 

which has been given by the user as : 

{ [Domain. 1, [Constraint.!.!, .... Constraint. !.n] ] , 

[Domain_2, [Constraint. 2.!, Constraint_2.n] ] , 

[Domain.m, [Constraint .m.i , Constraint m n]] 

> 

where Domain represents the domain over which the constraints are to be solved. 
The default Domain is ‘float’ and the default solver is ‘solve.float_equation’ if the 
constraints are specified without any details as shown below : 

{Constraint.!, Constraint.2 . . . , Constraint .n} 

The users may specify their own Domains and Solvers after the required constraint 
solvers have been interfaced. The user may specify the full details instead of the 
Domain above as : 

[real, rpc, machine.name=tejas, program.number=99 , 
ver s i on_numb er = !] 

where Domain is ‘real’, Strategy is ‘rpc’, the machine on which the solver is present 
is ‘tejas’ and further parameters are specific to remote procedure calls. Those fields 
which are left unspecified have default values. 

9.2.1 Interface Routines for Internal Solver 

The following routines have been defined for interfacing internal solvers to the in- 
ference engine. 

A] convert_term_to_constraint Jform This routine is used to convert the VAM 
terms specified in Prolog into an internal form suitable for manipulation by the 
Internal Constraint Solver. All Variables are replaced by distinct names for use 
by the constraint solver. This routine must be invoked before invocation of the 
constraint solver with a new constraint. 
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B] convert_constraint_to_term_form This routine which is the inverse of A] 
converts the terms from the internal form suitable for the constraint solver to VAM 
code required by the Prolog Inference Engine. This routine needs to be invoked 
only when symbolic outputs are desired. Till then the interface/ solver will hold the 
constraints in unconverted form. The new set of collected constraints when required 
can be converted to VAM form with variables and output symbolically. 

C] solve_constraints This routine is invoked whenever any constraint variable 
is changed or any new constraint is added. This invokes the proper constraint 
solver with the newly added constraint in internal form along with the earlier set of 
simplified constraints also in internal form which were retained on the Constraints 
Stack and determines whether the augmented Set is Consistent or Inconsistent with 
the existing set of constraints. If the solver itself is able to retain the earlier set 
of constraints (i.e. it is backtrackable), then no constraints need to be held on the 
Constraint Stack. Only fresh constraints need to be given to the solver in internal 
solver form. If the solver returns an output set of constraints, then the returned 
contraints are held in the inference engine in the Constraints stack. 

D] output .constraints If the engine does not maintain the constraints but the 
solver does then the solver should provide a facility to show the current set of 
constraints directly and therefore this routine is separately required. 

9.2.2 Interface Routines for External Solvers 

For solvers on different machines, the internal form is to be converted to a form 
which the solvers can understand, and filters are used for this purpose. The same 
routines as above are used here also. Only the constraints are redirected to the filter 
if the solve-constraints call is for an external solver. The filter on the client side 
converts the internal form to a form which can be communicated over the interface. 
This format is fixed, so that new filters to be added on servers can all understand 
and use a single format. 

9.2.3 Interface Structure 

The Interface structure basically consists of a Dictionary currently implemented as 
a list of records (accessed sequentially) with each record of the form : 

(Domain, PrologVariable, SolverVariable, PermanentName) 

The Domain of a PrologVariable indicates the set of values which the PrologVari- 
able may take. Thus even if the SolverVariable is used across solvers, the Domain 
of the PrologVariable does not change. The variable pair consisting of the ‘Pro- 
logVariable’ and the ‘SolverVariable’ are the variables in the Inference Engine and 
the Constraint Solver respectively. Whenever terms are sent to the solver, the vari- 
ables are stored in a dictionary thus changing their status from variable to solver 
variable. This however in no way prevents unification of the solver variables by 
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the inference engine. Thus unification is allowed to be used in conjunction with 
constraint solving. Backtracking past the points where a variable was changed to 
a solver variable necessiates the changing back of the solver-variable status back 
to variable, thus removing the variable from the dictionary. Whenever a solver 
variable gets unified with a constant (atom, numeric or character), a new equation 
solver variable = constant’ needs to be sent to the solver. If a functor gets unified 
with a solver variable we assume that the functor is comprehensible to the solver 
and again send an equation ‘solver variable = functor(parameters)’ (Refer pow/2 
in hypotenuse example in beginning of Chapter Solvers) to the solver. If a normal 
prolog variable gets unified with a solver variable, we bind the solver variable to 
variable. If the solver variable unifies with another solver variable then an equation 
solver variablel = solver variable2’ is sent to the solver. These points have been 
explained further in later sections. Consider an example : 

goal -CX = Y + 3>, P(Y), write(X). nl. 

p(8). 

In the above case, Y is a solver variable which gets unified with 8. Thus an equality 
constraint ‘Y=8’ is sent to the solver. Note that we have used ‘=’. Our imple- 
mentation currently assumes that ‘=’ is understood by the solver as equality either 
directly or through the interface. If a Variable is used across incremental solvers, 
and the Variable is instantiated, then this value needs to be communicated to all 
the incremental solvers using this Variable. This is not implemented. Also a stack 
is required to store incompletely solved constraints if an incremental backtracking 
solver is not available. This is provided by the inference engine. Details about back- 
tracking for incremental solvers have been illustrated with examples in Appendix 
D.4. 

9.2.4 Interface from Inference Engine to Solver 

For passing constraints to a constraint solver, the constraints should first be con- 
verted to an internal form suitable for the constraint solver. 

If a Prolog Variable already exists in the Dictionary, then its corresponding 
Solver Variable is used for conversion of the Term to an Internal Representation. 
Note that the Solver Variable may in turn be bound to a simplified/unsimplified 
solution and if so, this solution will be used for conversion. However, if the variable 
does not exist in the Dictionary, then a new entry is added to the Dictionary with 
a new SolverVariable which is used for conversion. This is all that needs to be done 
before calling au internal solver. 

The constraint solver is invoked as soon as merging of constraints is done. The 
constraint solver will return with solutions attached to each of the SolverVariables. 
These solutions are directly suitable for reuse by the constraint solver since they 
are in internal form. However if the system of constraints is not satisfiable, then 
backtracking can be initiated here. 
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For every SolverVariable in the Dictionary, if the attached solution is minimal 
(e.g. a constant which cannot be further simplified), then it is converted to VAM- 
code and the converted code is substituted in the corresponding PrologVariable. 
Also, this record entry is removed from the Dictionary. If the SolverVariable is a 
Variable itself, then no solution has been computed for that variable and the entry 
is left as it is. Partial solutions are adso retained without modification. 

For External Solvers, first the same steps as above for Internal solvers are per- 
formed. Then during the conversion of each constraint to intermediate form for 
transmission over communication interface, the variables have to be noted to cre- 
ate the structure containing the Solver Variable and External Name for use over 
communication interface. This is called ‘CorrespondingVariables’. The External 
name is selected dynamically for the whole set of constraints in case of black-box 
solvers each time constraints are sent to the solver while for incremental solvers 
the Permanent Name from the Dictionary is used. Names Ql, Q2, ..., Qn are 
used as Constraint Variable Names to be sent to black box solvers. For incremental 
solvers, the variables once allocated a name must necessarily use the same name for 
communicating with the Incremental constraint solver because it wiU understand 
only the variable names that were given to it earlier. If new names are given to the 
same variable, the incremental solver is not in a position to understand this and will 
therefore treat the variables as new variables. Therefore the field PermanentName 
is required in the Dictionary. The permanent names given are PO, PI, ... Pm. 

9.2.5 Interface from Solver to Inference Engine 

For External Solvers, if results are returned in terms of variable names QO, Ql, etc, 
then for black-box solvers, all the variables can be resolved using the ‘Correspond- 
ingVariables’ List created as above. The incremental solvers will return results in 
terms of PO, Pi etc in case the results contain variables. It is possible however that 
some of these names are not present in the ’CorrespondingVariables’ because the 
incremental solvers will return names it had retained in its earlier calls. Therefore 
the Dictionary needs to be used instead of the ‘CorrespondingVariables’ to resolve 
the variables in case of Incremental solvers when results are returned because of 
explicit call to output-variables. 

For Internal Variables, whenever partial /final solutions of Variables are to be 
output to the user, first the Dictionary is scanned for the presence of the Variable. 
If the variable is present in the Dictionary, then there are three options : 

1. If the solution attached to the SolverVariable is minimal, then this minimal 
solution after conversion to VAM-code is used for printing out the Prolog 
Variable specified. 

2. If the SolverVariable is itself a variable, then the corresponding Prolog Variable 
is printed out as Unbound. 

3. If the solution attached to the SolverVariable is not minimal, then this solution 
after conversion to VAM-code such that any Internal Solver Variables in the 
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solution are replaced by the corresponding Prolog Variables is used for printing 
out the Prolog Variable specified. 

If the Variable is not present in the Dictionary then it is not a variable used by the 
constraints and is directly output as a normal Prolog Unbound Variable. Note that 
any other structures produced by unification which are to be printed are already in 
VAM code form and therefore nothing special needs to be done to output them. 

9.2.6 Unification of Variables used in Constraints 
There are four possibilities to be considered : 

1. A Prolog Variable in the Dictionary (i.e. used in Constraints) will get bound 
(instantiated) to a Term which can be converted to solver form. 

2. A Prolog Variable in the Dictionary will get bound to another Prolog Variable 
already present in the Dictionary. 

3. The Prolog Variable in the Dictionary will get bound to a Prolog Variable not 
present in the Dictionary in which case nothing needs to be done. 

4. The Prolog Variable in the Dictionary will get bound to a term which cannot 
be converted to solver form in which case it is clearly a programmer error. 

These possibilities are compared in Table 9.1. The first three possibilities are elab- 
orated below : 

Bound Prolog Variables Before going to the constraint solver one or more of 
the Prolog Variables may get bound either by unification or because of solutions 
from constraint solvers invoked earlier. This condition is handled as follows . 

For every bound Prolog Variable (LHS) and its corresponding 
SolverVariable (RHS) in the Dictionary do 
■C Convert the VAM-code form LHS to the SolverForm TempRHS; 

Add an equation RHS = TempRHS to the set of constraints ; 

Remove this record from the Dictionary; 

} 

This is illustrated in the example below. 

No . Program 

(01) goal ■“ {Zl - A+B, Z2 = A-B} , 

(02) solvel(Zl), 

(03) solve2(Z2) , 

(04) write(A),nl,write(B),nl. 

(05) solvel(lO.O). 

(06) solve2(2.0). 


^ L t.. * 


51 



Z1 and Z2 are Prolog Variables used in constraints (same is the case with A and 
B). 

The converted constraints are as shown below : 

C_Z1=_A+_B, _Z2=_A-_B] 

The underscore before a variable name indicates that it is a Name substituted for 
the variable (i.e. a SolverVariable). After they have been merged in Line Number 
(01) above, the Dictionary will be : 

[(float ,Z1 , _Z1 , , (float , Z2 . _Z2 ,_) , 

(float,A,_A,_) , (float ,B,_B,_)] 

Now, in solvel(lO.O) in Line Number (05), Z1 unifies with the VAM-code [v(3), 
const( real( 10.0 ) )] which is actually the real number 10.0 and since there is a 
c_nogoaJ for code produced for solvel meaning that predicate solvel has no subgoals, 
it has only a head which has already been unified, therefore the routine ‘check_and- 
jsolve.constraints’ is called. This finds the list as : 

[(float, [constant, const (real (10.0))] ,_Z1,_) , 

(float , Z2 , _Z2 , _) , (float , A , .A , _) , (float , B , .B , _) ] 

An equation _Z1 = 10.0 is added as a constraint and passed on to the constraint 
solver and the first record is removed from the above Dictionary. A similar condition 
occurs at solve2 on line (06) when Z2 gets unified with [constant, const(real(2.0))] 
and the corresponding entry is removed from the Dictionary. Finally, this results in 
the output : 


6.0 

4.0 

meaning that A is assigned a value of 6.0 and B a value of 4.0. 

Duplicate Prolog Variables There is a possibility that two or more variables 
which were independently inserted into the list of constraints get unified later by 
the Inference Engine or by the solution of constraints by any of the constraint 
solvers. This causes duplicate entries of Prolog Variables in the Dictionary. The 
corresponding Solver Variables (possibly attached to simplified constraint solutions), 
however will be different unless this duplication has been caused by the action of a 
constraint solver itself. To take care of this possibility before going to the constraint 
solver, a check for duplicate variables has to be made. Thus, 

For every pair of records (R1,R2) where 

R1 is (Domain, PrologVariable,SolverVariablel,PermNamel) and 
R2 is (Domain, PrologVariable,SolverVariable2,PermName2) 
with duplicate PrologVariable do 
•C Add an equation SolverVariablel = SolverVariable2 
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to the set of constraints, over ‘Domain’. 

Remove one of the records, either R1 or R2 from the 
Dictionary. 

(One of the records must be retained) . 

> 

This is illustrated by the example below : 

No . Program 

(01) goal {Z1=A+B, C-B=A, A+C=2*B, Z2=A-B+C+1}, 

(02) eq(Zl,Z2), 

(03) write(A) ,nl, write (B) ,nl,write(C) ,nl. 

(04) eq(A,B) A=B. */ unification here 

Initially on line number (01), the four constraints will be given to the constraint 
solver. Zl and Z2 are separate variables. The constraints are converted to an 
internal form : 

C_Z1=_A+_B, _C-_B=_A, _A+_C=2*_B, _Z2=_A-_B+_C+1] 

The Dictionary is ; 

[(float ,Z1 . _Z1 , _) , (f loat ,Z2 ,.Z2 ._) , 

(float, C,_C,_) .(float, A, _A,.) .(float, B,_B,_)] 

The constraint solver will simplify the constraints resulting in a new Dictionary : 

[(float, Z1,1.5*_B+ -1.0*.B+_B,_). 

(float , Z2 , 1 . O+.B , .) , (float , C , 1 . 5*.B , _) . 

(float,A,1.5*_B+ -1.0*_B,_). (float ,B,_B,_)] 

Later at line number (02), the invocation of predicate eq defined on line number 
(04) results in unification of Zl and Z2. Thus while checking for duplicate variables. 
Variables 1 and 2 are found to be duplicate. The partial solutions are shown below : 

Duplicate 1,2 
1: :PrologV<iriablG:Z2 

SolvGrVaxiablG:1.5*_B+ -1.0*_B+_B 
2: :PrologVariablG:Z2 

SolverVariable : 1 . 0+_B 

Therefore a new constraint : 

float, [1.0+_B=1.5*_B+ -1.0*_B+_B] 

is created and added to the list of constraints to be sent to the constraint solver. 
Entry 2 marked above will be removed horn the Dictionary. This finally results in 
the correct output shown below : 

1.0 

2.0 

3.0 

That is, A has value 1.0, B has value 2.0 and C has value 3.0. 
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Unifying a Prolog Variable used in Constraint with a normal Prolog 
Variable In this third case, we have used the approach of just unifying the two 
variables directly. However this approach could present a problem. We elaborate 
this possibility with an example shown below : 


01: goal 

02: freezeCC, freezeCD, C > D)), 

03: -CA+BsT.O}, 

04: C=A, D=B, */, Case 3 applies here 

05: •CB-A=1.0}, 

06: write(A) ,srite(B) ,write(C) ,writeCD) . 


It is expected that a failure occurs after the constraint on line 05 is solved. This is 
because we expect that C = A = 3.0 and D = B = 4.0. This implies that C < D 
and not greater than as frozen on line 02. However on actual execution it is seen 
that goal completes execution and outputs the expected values. But there is stiU 
the unsolved frozen goal C '> D- This happens because internally the variables C 
and D are still uninstantiated. It is only the replicas of the variables _C and _D used 
in constraints which have been instantiated. Therefore C > D was never executed. 
However, the required values were output because only the write can directly access 
the Constraint Variables of the corresponding Prolog Variables. 

This possibility can occur only if a program is specifically written for doing so. 
However in normal examples, this condition does not arise. Taking care of this 
possibility fully will present a lot of overhead in searching for every frozen Prolog 
Variable in the Dictionary to find whether its corresponding Constraint Variable (if 
found) is instantiated and thus take proper action.However a simple way out could 
be to assign values returned by the solver directly to the Prolog Variables and do 
away with the Solver Variables completely. If this is done, then goal in the above 
example will fail as expected. This was the approach we had followed in the meta 
interpreter as illustrated by the example in Figure 3.1. However the problem in this 
case is that a special call to sum-ofjproducts to simplify the final solutions is required. 
This is because the solver returns incompletely simplified solutions (terms) 
get unified with variables, although they have a chance of being further simplified. 
Since the variables get instantiated to unsimplified solutions because of the strategy 
of earliest; substitution, the structures which are returned by the solver are the ones 


that are output. Cleaxly this is not desirable. , j i.i. o 

Another possibility is that only fully simplified solutions attached to the Con- 
straint Variables are communicated to their corresponding Prolog Variables. Doing 
this will allow the goal to fail as expected. Also the outputs wiU present no problem 
because they axe assigned only if they are completely simplified. This approach is 
also not sufficient, however, because in the above example it is quite P°^le th^t 
instead of the values 3.0 and 4.0 we got by solving the set of constrmnts {A+B- 7.0 
and A- B = 1.0} we may get some terms containing variables for some different 
set of constraints,’and these terms are not in minimal form. Also instead of the 
C > D, we may have a complicated frozen predicate. In this case also the above 


54 



Unification Possibility 

Change in dictionary 

Action 

Bound Prolog Variable 

Remove instantiated 
entry 

Add new constraint 
converted(LHS)=RHS 

Duplicate Prolog Variable 

Remove one of the 
duplicate entries 

Add new constraint 
RHS1=RHS2 

Prolog Variable with 
normal Variable 


Unify variables 

Prolog Variable with 
incorrect Term 

1 

Programmer Error 


Table 9.1: Possibilities in Unification 


example will be solved incorrectly and this is not desired. 

A final possibility is that if a Prolog Variable, say A, in the Dictionary is to be 
bound to a Prolog Variable B not present in the Dictionary, then instead of binding 
A to B, we communicate the current value of the Solver Variable _A corresponding 
to the Prolog Variable A to B. This approach will also allow the above goal to fail 
as desired. This approach is also not sufficient. 

Since taking care of this third case completely implies searching the dictionary, 
and the dictionary could be quite large, we assume that freeze and constraints are 
not used in the same program in a way that could create problems, and do not 
implement this strategy. 


55 




Chapter 10 

Adding a new constraint solver 


Adding solvers to create a new system is a task simply of specifying the details of 
the solver to be added. A filter needs to be written to convert from the intermediate 
language to the form understandable by the solver being added and then to reconvert 
the results returned by the solver to the intermediate format. We show examples of 
adding three different solvers. 

10.1 Boolean Black Box Solver 

Suppose that a solver for boolean constraints is to be added. The boolean solver 
is available such that the inference engine and the solver can share the same file 
system. We use the basic type ‘inf as the domain for boolean. The details of this 
boolean solver are specified in the advice database as ; 

get _detail(boolean,file_number,[] ,10)* 

get _detail(boolean ,solver Jdnd, [] , black-box) . 

All that is required is that the constraint solver along with its interface must be 
executing on the remote/same machine. Now the program which requires this con- 
straint solver can execute directly. Thus the user can use a new constraint solver 
quite easily. 

Consider the following example taken from [2]. Refer to Figure 10.1. 

/* Cross circuit */ 

/* Problem is to prove that circuit is a cross circuit */ 

/* Ref : "CAL", Page 273 Proc. FGCS 1988 */ 
circuit (X,Y, A, B) 

•[ [boolean, [14 = C" X) or 13, 

13 = X and Y, 

IS = (' Y) or 13, 

18 = (' 14) or 13, 

19 = (' 15) or 13, 

A = 14 and 111, 

111 = 18 or 19, 
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] ] 

}. 


goal circuit (X,Y, A, B) , 

write ( ’ X= ’ ) .write (X) ,nl , 
write ( ’ Y= ’ ) , write (Y) ,nl , 
write (’A=’), write(A),nl, 
write (’B=’), write(B),nl. 

In the above problem, the specification of the circuit has been described in terms 
of boolean equations. The relation between input and output terminals is also 
described, ‘and’ and ‘or’ are taken to be binary infix operators (functors) and ‘"’ as 
a prefix unary operator (functor) for negation. When goal is executed, the resulting 
output is : 

X=_X 

Y=.Y 

A=_Y 

B=_X 

where _X and _Y are variables. This is because, all the arguments in the query 
“circuit” were left free. The values which A, B, X, and Y can take are ‘int’ (used 
as boolean). 

The domain ‘boolean’ specified in the above program is used to find details for 
the invocation of the requisite solver. A text filter is used by default. Refer to 
Example-103 and Example-105 in Appendix D for use of the boolean solver using 
the same common file system. 

10.2 Real Black Box Solver 

The details for a black box solver for domain real for which basic domain atom 
provided by the modified VAM is used, running on machine tejas with other details 
of ‘rpc’ is shown below : 
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get_detail(real, machine-name, Ojtejas). 

get_<ietail(real,constraint_prog,[],99). 

get_detail(real,constraint_vers,[],l). 

get_detail(real, function-number, [],1). 

get-detail(real,tcp-udp,[],’tcp’). 

get-detail(real,solver-ldnd,[],black-box). 

We can have a number of real solvers on teja^ itself with different constraint-prog. 
We can change the name tejas to vayu if the real solver is available on machine vayu. 
As long as the solver is executing as a server on some machine and the interconnec- 
tion network is up, all that needs to be done to attach a solver is specification of 
above details. Now the solvers can directly be used in the user program. Nothing 
more is necessary. Refer to Examples 101, 102, 105 in Appendix D for use of black 
box solvers in user programs using remote procedure calls (‘rpc’ mechanism). 

10.3 Real Incremental Solver 

The details of an incremental solver for domain inc_real for which basic domain 
atom provided by the modified VAM is used, running on madiine tejas with other 
details of ‘rpc’ as actually used in the current implementation is shown below : 
get-detail(inc_real,machine_aame,Q,tejas). 
get-detail(inc-real,constraint.prog,0,97). 
get-detail(incjreal,constraint_vers,Q,l). 
get _detail(inc-real,function_number ,[],!) . 
get_detail(inc-real,tcp-udp,[],’tcp’). 
get _detail(inc-real, solver-kind , [] ,incremental). 

Again in this case, nothing more needs to be done. Proper calls will be made 
to the incremental solver from the inference engine and outputs will be interpreted 
properly. Thus the incremental solver may be used easily by the user. Refer to 
Example- 104 in Appendix D for use of an incremental solver for domain real. 
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Chapter 11 


Conclusion and Future Work 


11.1 Summary 

We have presented a Modular Constraint Logic Programming System which allows 
the addition of different constraint solvers through the medium of an interface be- 
tween the solvers and the inference engine. A solver is essentially a separate module 
and does not know anything about the inference engine. This allows selection of 
required solvers at run time. Fast prototyping of new CLP systems is thus possible. 
Solvers may run on different machines on the network. A Constraint Solver Server 
has been designed which allows the inference engine to access constraint solvers with 
the help of an advice database. Our system models the client server relationship. 
The inference engine forms the client and the constraint solvers are the servers which 
are remotely distributed. The solvers axe contacted only when relevant constraints 
are to be solved. Thus the solvers can service a number of clients. Although the 
system in its current form is slow, we have demonstrated that it works for a number 
of real world problems. In this first level implementation we have not concentrated 
on efficiency but have successfully developed a prototype to illustrate the working 
of our design. 


11.2 Current Implementation 

A black box constraint solver using remote procedure calls for communicaton is 
implemented for domain Real on top of IF /Prolog on the HP-9000/850. This solver 
is invoked by the inference engine written in Quintus Prolog on the SUN-3 worksta- 
tions. The HP-9000 and the SUN-3 workstations are connected through the Eth- 
ernet. We have also implemented the boolean and floating point constraint solvers 
on the SUN-3 which can also be invoked by the inference engine directly (Internal 
solvers). The boolean solver may be invoked using the sameJfs strategy. An incre- 
mental solver for domain real has also been written on HP-9000/850 on IF/Prolog 
and it can also be invoked by the inference engine alone or in combination with 
other solvers. 
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Program 

Solver 

Time Teiken 

dc_circl 

External Real Black Box Solver 

61.150sec -1- 55.0sec. 

dc-circl 

Internal Float Black Box Solver 

44.817sec. 

dc_circ2 

Internal Float Black Box Solver 

207.984sec. 

dirichlet 1 

Internal Float Black Box Solver 

25.3345ec. 

dirichlet 1 

External Real Black Box Solver 

6.617sec 55.0sec. 

dirichlet2 

Internal Float Black Box Solver 

0.767sec, 

dirichlet2 

External Real Black Box Solver 

0.800sec + l.Osec. 

meals 

Internal Black Box Float Solver 

3.084sec. 

meals 

External Black Box Real Solver 

4.350 -f 9.0sec. 

meals 

External Incremental Real Solver 

5.167 -1- 13.0sec. 

mortgage 

Internal Float Black Box Solver 

114.600sec 

mortgage 

External Real Black Box Solver 

120.067sec -p IGO.Osec 

mortgage 

External Incremental Real Solver 

120.783sec + 180.0sec 


Table 11.1; Execution Timings for some Constraint Logic Programs 


Tbe Vienna Abstract Machine has been extended to handle constraints. A 
number of large problems have been solved for testing the implementation. These 
include the Dirichlet problem for Laplace’s equation for two dimensions, Electrical 
Engineering Problems [15], and Options trading Problem [19]. 

The practice of analyzing the complexity of Prolog Programs is not as devel- 
oped as for programs in conventional programming languages. There has been little 
agreement on Prolog benchmarks other than LIPS or logical inferences per second 
which is probably the best measure. However we have noted the total time required 
for some of the programs from Appendix F to execute on the current implementa- 
tion. These are shown in Table 11.1. 


11.3 Applications 

Constraint-based languages and systems have a demonstrated utility for a wide va- 
riety of applications including geometric layout, physical simulations, user interface 
design, document formatting, algorithm animation, design and analysis of mechani- 
cal devices and electrical circuits, and even jazz improvization [4]. Our system may 
be used to solve real world problems in a number of areas. Some applications in 
Scheduling and Planning as well as in Circuit Design are listed below : 

Operations Research It consists of an inexhaustable source of interesting search 
problems, especially large scale scheduling and planning problems. 

Disiuctive Scheduling Consider a problem in Civil Engineering. Problem is to 
minimize the total duration of building a bridge with precedence and disjunc- 
tive constraints due to the Umited availability of resources. 
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Graph Colouring The problem is to find the minimum number of colours to label 
the vertices of a graph such that no two adjacent vertices are assigned to the 
same colour. 

Car Sequencing This problem occurs in the scheduling for the assembly line of 
car manufacturing. Each car may require a different set of options and the 
assembly line has capacity constraints for the options. The problem is to 
generate a sequence of cars which satisfies the capacity constraints. 

Optimal traffic assignment for satellites This problem is concerned with the 
scheduling of onboard switching systems in telecommunication satellites. The 
problem can be formulated as follows : given an interstation traffic matrix, 
determine the successive switching modes to switch all the traffic requirements 
in minimum time. 

Warehouse location The problem is : given a set of warehouse locations, a set 
of customers, and the costs of stocking and transportation from warehouses 
to customers, to find an optimal configuration of the warehouses (i.e. their 
number and locations) which minimizes the total cost. 

Cutting problems The problem consists in cutting two dimensional shelves of 
various sizes according to customer requirements from standard wood boards 
in a furniture factory. The objective is to minimize the total waste. 

Investment planning The program chooses among different investment types in 
order to minimize or maximize a goal function over a given period. Using the 
symbolic simplex method, the program yields the most general solution and 
the user can then interact with it to get the best solution with regards to his 
need. 

Circuit simulation Simulation of large combinatorial and sequential circuits is 
possible. 

Symbolic Verification The formal comparison of an implementation of the circuit 
with its functional specification (usually a set of boolean equations) is possible. 

Circuit Synthesis Problem is to automatically generate a circuit at the transis- 
tor level (in different technologies) from a truth-table or boolean equation 
specification. 

Fault diagnosis The problem is to locate a faulty component in a circuit from its 
input /output misbehaviour. 

Automatic test-pattern generation Problem is to generate a minimal number 
of test patterns to detect aU single stuck-at errors in combinational circuits. 

Circuit specialization and simplification The problem is : from a description 
of a circuit which performs a set of functions, to derive a more specialized 
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one performing only a subset of the functions. The goal is to minimize the 
number of components in the simplified circuit. 

Channel routing This application comes from the area of VLSI layout design. 

It consists in connecting terminals on two sides of a rectangular channel in 
presence of certain constraints. The objective is to minimize the channel 
width. 

Microcode label assignment This application comes from the area of computer 
firmware development. The problem is to assign labels of symbolic microcode 
to addresses in a page of microcode memory. Branch instructions generate 
constraints on certain bit patterns. 

Some examples are included in Appendix F. 

11.4 Future work 

Our system is currently slow because the VAM is being simulated in Prolog. How- 
ever if VAMip is used and code translated to machine code instead of simulating 
it, the speed will increase significantly. We have concentrated on designing a model, 
and not on optimization. Issues on optimization have been dealt with in [28]. 

Although new constraint solvers can be added, the representation of constraints 
is currently limited by the basic domains available in our implementation. An 
intermediate language must be designed which is the output of the filter from the 
inference engine side. This intermediate language can then be used by any of the 
filters on the solver side to convert it to a form understandable by the solvers. 

A graphics interface needs to be added and the user should be allowed to specify 
his own domains in a proper format. 

Specifications of constraint hierarchies may be added for constraint satisfaction 
which could include both the required constraints and the default constraints of 
differing strengths. 

We are planning to further interface packages like Mathematica [33] and RE- 
DUCE [14] to our system. In the current implementation, we have restricted our at- 
tention to synchronous requests for solving constraints in which the client requesting 
solutions of constraints is suspended for the duration of the request. Asynchronous 
requests are certainly possible due to the inherent parallelism in the specification of 
constraints and these operations may be parallized. 
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Appendix A 

Reference Manual 


Predicate Name/ 
Topic 


Description 


abort Aborts the execution of the current goal and returns to the simulator to 
query the user. 

asserta(+Clause) 

assertz(+Clause) Both forms of assert add to the predicate database. A clause is 
added for the predicate in a particular order with respect to existing clauses of 
that predicate. If the predicate does not exist, it is created by assert. Asserted 
clauses are not removed by backtracking. 

‘asserta’ adds Clause at the beginning of the predicate definition. 

‘assertz’ adds Clause at the end of the predicate definition. 

Refer Example-01, Example-02 and Example-04 in Appendix C. 


bye 

end_ofJlle Terminate the current VAM-simulator session. 


call(?Goal) 


execute(?Goal) Goal must be instantiated to a term that can be interpreted as a 


goal. 

call/l succeeds if an attempt to prove or satisfy Goal succeeds. The caR/1 
instance is textuaJly replaced by Goal, i.e. it is transparent. Thus a cut m 
Goal has an effect at the level of caJl/1. 


execute/1 succeeds if an attempt to prove or satisfy Goal ^ a subgoal succ^ds 
A cut in Goal is executed as a subgoal and does not affect choice points a 
the level of execute/1. Refer to Example-14 in Appendix C. 
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clause(?Head, ?Body) The expression “clause” refers to a fact or a rule. A clause 
consists of a head that is positioned at the left of the conditional and a 
body that is positioned at the right of same (Head Body) . The head is made 
up of a term and the body which is a combination of rule calls. A nonexistent 
body is equivalent to a body declared as “true”. 

clause/2 searches the database for a clause whose head matches Head. Head 
must be bound to a nonvariable term. The head and body of those clauses 
are unified with Head and Body respectively. If the clause is a unit clause, 
Body is unified with ‘true’, clause/2 backtracks to find all the clauses with 
matching head. 

comment Comments either start with the end of the current line or 

/* and extend over arbitrarily many lines until */ is encountered. Nested 
comments are not allowed. 

cut Cut (discard) all choice points created since the parent goal started execu- 
tion. The cut affects all clauses of the parent goal. Refer to Example-01 and 
Example-08 in Appendix C. 

debug Puts the debugger flag on 

nodebug Puts the debugger flag off 

fail This predicate always fails. It is useful in the “ !, fail ” combination. It s also 
useful when it is desirable to backtrack through all solutons. 

help Show help on screen 

-Z is -f ArithExpr Used for evaluating arithmetic expressions. 

listing Lists all clauses in the database. 

listing(-t- Functor) Lists all clauses in the database with the head Functor. 

nl Display a newline. 

nonvar(-f-Term) nonvar/1 is true if Term is currently uninstantiated. 

numeric(-f Term) Arithmetic type testing predicate is true if Term is instantiated 
to an integer or real value. 

retract(Clause) The Head must be sufficiently instantiated to specify a predicate 
(functor and arity). retract/l deletes the first clause in the Datable that 
matches clause. As retract is backtrackable, it successively retracts aH clauses 

of the predicate. 

stat Shows the current statistics on the console. 

struct(-l-Term) struct/1 is true if Term is a Structure. 
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term A term is either a structure, a variable or a constant. Integers, reals, atoms, 
characters, strings, are constants. Terms of the form functor(Argl, Arg2, ...) 
and Lists are structures. Every clause in the program is also a term. 

true This predicate always succeeds. 

unification 

?Terml = ?Term2 

-4-Terml != +Term2 =/2 is called “unify”. If Terml and Term2 can be unified, 
they are unified and the predicate succeeds. Do not confuse =/2 with the 
arithmetic evaluation/assignment operator is/2, and the arithmetic compari- 
son operator ==/2. \= 2 is called “not unifiable”. If terml and Term2 can 
not be unified, the predicate succeeds. It is defined as the clause “not Terml 
= Term2”. 


univ =.. 

?Structure =.. - UnivList 

-Structure =.. ? UnivList The operator =.. is the univ operator. When this 
predicate succeeds, UnivList is a list whose head is the atom that is the prin- 
cipal functor of structure and whose tail is the argument list of that functor. 
At least one of Structure and UnivList must be instantiated when =../2 is 
invoked. If Structure is uninstantiated, then UnivList must be instantiated 
either to a list of determinate length (whose head is an atom) or some functor. 

Refer to Example-03 in Appendix C. We use the same private symbols which 
Quintus Prolog provides, an underscore followed by three or more digits. An 
user cannot refer to particular internal variables by these names, even when 
using an underscore in the name. 

var(-l-Term) var/1 is true if Term is currently uninstantiated. 

variables Variables are distinguished syntactically from other terms by an initial 
capital letter. A variable is thought of as standing for some particular but 
unidentified object. A variable is not simply a writable storage location as 
in most programming languages; but rather it is a local name for some data 
object. 

If a variable is only referred to once, it does not need to be named and may 
be written as an “anonymous” variable, indicated by the imderline “_ alone. 
This symbol succesfuUy unifies with anything. Refer to Example-06 in Ap- 
pendix C. Variables will be internally used either as Prolog Variables or as 
Constraint Variables. 

write/- Writes out terms on the console. Special write, writeq, display, displayq 
are not defined. 
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write_frozen^oals/0 Displays the current set of frozen goals. 
•write_constraints/0 Displays the current set of unsolved constraints. 


Arithmetic operators : -Result is . . 


+ +Arith_exprl 
- +Arith_exprl 
+Arith_exprl + +Arith_expr2 
+Arith_exprl - +Arith_expr2 
+Arith_exprl * +Arith_expr2 
+Arith_exprl / +Arith_expr2 
+Arith_exprl // +Arith_expr2 
+Arith_exprl mod +Arith_expr2 

Comparison Predicates 


+Arith_exprl < +Arith_expr2 
+Arith_exprl =< +Arith_expr2 
+Arith_exprl \== +Arith.expr2 
+Arith.exprl > +Arith.expr2 
+Arith_exprl >= +Arith.expr2 
+Arith_exprl == +Arith_expr2 


unary plus 
unary minus 
addition 
subtraction 
multiplication 
real division 
integer division 
modulo 


less than 

less than or equal 

Not the same instantiated value 

greater than 

greater than or equal 

the same instantiated veQ.ue 
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Appendix B 


Comparison of VAM with 
WAM 


The Vienna Abstract model is different from other implementation models with 
respect to ; 

1. The stack and instruction pointers, 

2. The content of stack frames and choice points, 

3. The implementation of Unification. 

In contrast to VAM, the WAM splits the process of inference into a parameter 
passing and a unification part. To perform an inference, (a) The parameters are 
passed via argument registers using put and unify instructions, (b) The control is 
transferred to the called clause, and (c) The parameters in the argument registers 
are unified with the arguments of the head using get and unify instructions. 

Thus WAM goes ; 

put, put, ..., call<p>, get, get, ... 

VAM makes puts and gets at once. It goes : 

c_goal+c-call<p>, g_Any+hAny, g_Any+hAny, ... 

Whereas WAM creates data superfluously on the copy stack (HEAP) for uni- 
fying ground structures which are both in goal and head, VAM creates no terms 
at all for ground programs. VAM although being a structure copying interpreter, 
has properties similar to those of structure sharing. The different implementations 
of inferences influence the memory model, memory utilization, and runtime perfor- 
mance. 

WAM’s argument registers need to be saved in the choice point and therefore 
choice point creation and backtracking (especially shallow backtracking) are more 
expensive when compared to VAM. On backtracking, VAM has to execute put+get 
instructions of the goal and the next clause. WAM has to execute get instructions 
only. WAM’s overhead of restoring the arguments is approximately eqmvalent to 
the “put-overhead” (of fetching g-Any’s) in case of VAM. In general, the VAM has 
fewer trailing and dereferencing operations. 


70 



In the VAM, temporary variables cannot be shared between the head and the 
first subgoaL Variables only occnring in the head and the first goal must be stored 
as permanent (local) in VAM. Therefore in clauses with more than one subgoal, the 
stack frame is larger for the call of the first subgoal provided that WAM can share 
temporaries (typically 2 to 3 elements). In determinate clauses with one subgoal, 
VAM’s increased stack frame is removed by last call optimization. If such a clause 
is nondeterminate, VAM’s stack frame is similar in size to WAM’s bigger choice 
point. 

The VAM needs a smaller copy stack size because VAM has no (or fewer) unsafe 
variables, and because goal structures need not be stored on the copy stack if they 
are unified with a void variable of the head or with a matching structure. 
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Appendix C 


Test Routines for VAM 
simulator 


C.l Checking asserta fact 


/♦ Example 01 : AAK 

Checking asserta of a fact/clause "factorial (1 ,1) !". 

Executing goal will assert the first clause for 
factorial and enable proper execution of the call 
to factorial later. 

*f 

f actorialCN.Res) 

N1 is N-1, factorial(Nl,Temp) , is(Res,*(Temp,N)) . 
goal assertaC(factorial(l,l) !)),fail. 
goal : - 

listing(factorial) , 
factorial (5, X) , 
write(X), nl. 


Goal : goal. 


■SIMULATING' 


factorialCl, 1) 

I , 

factorial (N, Res) 
is(Nl, -(N. D), 
f actorialCNl, Temp), 
is (Res, *(Temp, N)). 

120 

XXX - 

Frozen Goals : □ 


XXX 

Constraints : □ 
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C.2 Checking assertz fact 


/* Exzmple 02 : AAK */ 

/* Checking asserta and assertz and cuts */ 

7. First execute goall to check asserta, 

7, then execute goal2 to execute assertz 

goall assert2C(work(A,bbb(ccc)) :-true)), 

work(‘c,bbbC_)) . 
goal2 assertaC 

(work(A,bbb(ccc)) 

workl(A) ,work2(B) ,f ail 

) 

). 

work(‘c,bbb(_)) . 

workl(X) write(X,"Workl") ,nl, ! . 

worklCX) writeC'Should never come here"),nl. 

work2(X) write (X, "Work2" ) ,nl. 

work2CX) writeC'Should always come here"),nl. 

work(C,D) write (C,D, "End of execution"). 

Goal : goall. 

SIMULATING 

aaa 

Warning : AAK : Asserting a clause containing variables 
Created temporary vzuriables : [TVO] 

‘cbbb(_399) "End of execution" 

XXX XXX 

Frozen Goals : □ Constraints : □ 

Goal : goal2. 

SIMULATING 

aaa 

Warning : AAK : Asserting a clause containing variables 
Created temporary variables : [TVO] 

‘c"Workl" 

_590"Work2" 

"Should always come here" 

‘cbbb(_267)"End of execution" 

XXX X3CX 


Frozen Goals : □ 


Constraints : □ 



C.3 Towers of Hanoi using a memo-function 

Memo functions save the results of subcomputations to be used later in a compu- 
tation. Remembering partial results is impossible within Pure Prolog, so memo- 
functions are implemented using side effects provided by assert to the program. 
Programming in this way may be considered bottom up programming. 

The prototypical memo-function is lemma(Goal). Operationally it attempts to 
prove the goal Goal, and if successful, stores the result of the proof as a lemma (See 
clause for lemma below demonstrated for solving the Towers of Hanoi problem). 
The next time P is attempted, the new solution will be used, and there will be no 
unnecessary computation. The cut is present to prevent the more general program 
being used. Its use is justified only if P does not have multiple solutions. 

hanoiCl,A,B,C, [A to B]). 
hanoi(N,A,B,C,Moves) N > 1, 

N1 is N-l, 

lemina(hanoi(Nl,A,C,B,Hsl)) , 
hanoi(Nl,C,B,A,Ms2) , 
appendCMsl, [A to BlMs2] .Moves) . 
append( □ ,Z,Z) !. 

append([X|Y] ,Z, [XiRest]) append (Y.Z, Rest ) . 
lemma(P) call(P) ,asserta((P !)). 
testhanoiCN, Pegs, Moves) 

hanoi(N,A,B,C,Moves) , Pegs=[A,B,C] . 

It is well known that the solution of the Towers of Hanoi with N disks requires 
2^“^ moves. The performance is dramatically improved in the above program. 

The solution to the Towers of Hanoi repeatedly solves subproblems moving the 
identical number of disks. A memo-function can be used to recall the moves made 
in solving each subproblem of moving a smaller number of disks. Later attempts to 
solve the subproblem can use the computed sequence of moves rather than recom- 
puting them. 

The program is tested with the testhanoi(N, Pegs, Moves). N is the number of 
disks. Pegs is a list of three peg names and Moves is the list of moves that must 
be made. Note that in order to take advantage of the memo-functions, a general 
problem is solved first. Only when the solution is complete, and aU memo-functions 
have recorded their results, are the peg names instantiated. 

Goal :tasthanoi(4, [a,b,c] .Moves) . 

SIMULATING 

Warning ; AAK : Asserting a clause containing variables 
Created tempor 2 iry variables : [TV0,TV1,TV2] 

Warning : AAK : Asserting a clause containing variables 
Created temporary variables : [TV0,TV1,TV2] 
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Warning : AAK : Asserting a clause containing variables 
Created temporary variables : [TV0,TV1,TV2] 

XXX XXX 

Frozen Goals : □ Constraints : □ 

Moves : [toCa, c) , to(a, b) , to(c, b), to(a, c) , to(b, a), 

to(b, c) , to(a, c) , to(a, b), to(c, b) , to(c, a), 

to(b, a), to(c, b) , to(a, c), to(a, b) , to(c, b)] 

In the process the following three clauses have been added. (This is found by giving 

the goal listing (hanoij). 

hanoiO, TVO, TVl, TV2. 

CtoCTVO, TVl), toCTVO, TV2), to(TVl, TV2) , 
toCTVO, TVl), to(TV2, TVO), to(TV2, TVl), 
toCTVO, TVl)]) 
hanoiC2, TVO, TVl, TV2, 

[toCTVO, TV2), toCTVO, TVl), toCTV2, TVl)]) !. 
hanoiCl. TVO, TVl, TV2, [toCTVO, TVl)]) !. 


C.4 Using structures and unnamed variables 

/* Example 03 : AAK */ 

/* Checking multiple "_"es and use of structures *! 

goal personCName, dateofbirthC_,monthC6) ,_)) , 
writeCName) ,nl, fail- 

goal. 

personC'Jonny" ,m,ageC23) ,hobbiesC [reading, swimming] ) , 
dateofbirthCdayCS) ,monthC6) ,yearCl968))) . 

personC'Robert" ,m,ageCl5) , hobbies [[reading, swimming]) , 
dateofbirthCdayClS) , month C7) , year C 1985)) 

person C'Meena" ,f ,ageC20) , hobbies C [eating, swimming] ) , 
dateofbirthCdayClS) ,monthC6) ,yearC1975)) 

). 


Goal : goal. 

SIMULATING' 

"Jonny" 

"Meena" 

XXX 

Frozen Goals : D 


XXX 

Constraints : □ 
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C.5 Chedsing assertion of a clause with variables 

/* Example 4 : AAK */ 

/* Checking asserta of clauses with variables */ 
new_hi(X) write(X),nl. 
goal : - 

assert a(( 
hi(X):- 

write ("Executing the code ", 

’ (new_hi(X) write (X) ,nl) ’ , 

'/, Note: What happens if the single quotes making the above line 
*/, an atom are missing? 

7, Answer : These X also get bounded when hi (123) is called, 
"with X = 123." 

). 

nl, new_hi(X) 

)). 

hi(123), writeC'Done") ,nl. 

Goal : goal. 

SIMULATING 

aaa 

Warning : AAK : Asserting a clause containing variables 
Created temporary variables : [TVO] 

"Executing the code "(new_hi(X) write (X) ,nl)" with X = 123." 

123 

"Done" 

XXX 

Frozen Goals : □ Constraints : □ 


C.6 Checking Univ 


/* Example 06 : AAK */ 

/* Checking =.. Univ */ 
goal I “ 

aaa(X,ccc) =. . [F.bbb.ccc], write(X),nl, write(F). 
Goal : goal. 

SIMULATING 


bbb 

aaa 


Frozen Goals : D 


XXX 


XXX 

Constraints : □ 
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C.7 Checking call and execute 


/* Example 14 : AAK 

Testing call and execute. 

*! 

goall X = C!,fail), write(testl) ,call(X) . 

goall write(test2) . 

goal2 X = (!,fail), write (test 1) .execute (X) . 

goal2 write (test2) . 

Goal : goall. 

SIMULATING 

testl 

[Result :Unsuccessf ul .] 


Goal : goal2 . 
testltest2 
Frozen Goals : □ 


-SIMULATING- 


XXX 


XXX 


Constraints : □ 


C.8 Sorting : Checking cuts 


/♦ Using Cuts : Example 08 : AAK 
Making programs deterministic *l 
Problem ; Sort a given list of integers. 

♦/ 

strictmaxoftwoCX.Y.Y) Y > X.true. 

strictmaxoftwo(X,Y,X) >(X,Y). 

ismaxinlist ( □ , □ ) • 
ismaxinlist([Num],Num) :- ! • 
ismaxinlist ( [NumI Rem] .Max) ." 

Rem ismaxinlist TempMax. 

strictmaxoftwoCNum.TempMax.Max) . 


removefromlist (D »_»D)' 

removefromlistC [Maxi Rem] .Max, Rem) . 

removefromlist ( Dium I Rem] , Max , [Num 1 NewRem] ) : - 

removefromlistCRem.Max.NewRem) . 
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sortCD.D) !. 
sort (X , [Max I Rem] ) : - 
ismaxinlist(X,Max) , 
removefromlist(X,Hax,TempRem) , 
sort (TempRem, Rem) , ! . 

goal goall, goal2, writeC’Goall and Goal2 executed’), !, fail 
goall sort(C3,2,4,l] ,X) ,write(X) ,nl,fail. 

goal2 sort([10,12,ll],[12.X,Y]),sort([X,4,Y],Z),write(Z).nl,! 

goall sortCn ,Y) ,sort([5, 6,8,7] ,X) .writeCX) ,nl, ! . 
goal2 write ("Should never reach here"), fail, 

goal writeC'Second Goal"),nl,!. 

Goal : goal. 

SIMULATING 

[4. 3, 2. 1] 

[8, 7. 6. 5] 

[11, 10, 4] 

Goall and Goal2 executed 
[Result : Unsuccessful .] 

C.9 Permutations : Using dif and freeze 

/* Example 13 : AAK */ 

/* Shows use of freeze and dif predicates */ 
plusCA,B,C) 

freezeCA, freezeCB, either(U, suml(A,B,C)))) , 
freezeCA, freezeCC, either(U, sum2(A,B,C)))) , 
freeze(B, freeze(C, eitherCU, sum3(A,B,C)))) . 
suml(A,B,C) C is A + B. 

sxim2(A,B,C) B is C-A. 

sum3(A,B,C) A is C-B. 

eitherCU, P) var(U) , '. ,U=constant,call(P) . 

either (_,_) . 

goall 

plus (3 , 5 , Z) , write (Z) , nl , 
plus(3,Y,8) ,write(Y),nl, 
plus (X, 5, 8) , write CX),nl. 

list_of_one([llX]) writeC' .’),list.of.on6(X) . 

list_of_one(r.]) • 

length(L,N) freeze(L.length_new(L,N)) . 
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length_new( □ ,0) . 
length_nQw([E|L],N) 

dif(N,0), one_less(N,N_new) , length(L, N new). 
one_less(X,Y) Y is X - 1. 
dif(X,Y) freezeCX, freezeCY, X \= Y)). 

goal2 length.(L,5) , list_of _on6CL) , write(L),nl. 
outside_of (X , □ ) . 

outside_of(X,[YlL]) dif(X.Y). outside.of (X.L) . 
not_same(CXlL]) outside.of (X.L) . not_same(L) . 
not_same(C3) . 

permutationCL.N) length(L,N), not_same(L), all digitsCL). 
all.digits(D). 

all_digits(CXlL]) dig(X), all_digits(L) . 

dig(l) . 

dig(2) . 

dig(3) . 

dig(4) . 

dig(5) . 

goals asserta(count(0)) , fail, 
goals : - 

permutation(L,4) ,write(L) ,nl, 
retract (count (N)) , 

NewN is N + 1, 
asserta(count(NewN)) , 
fail. 

goals retract (count (N)) .write (’Count = ’) .write(N) .nl. 

Goal : goall. 


8 
5 
S 

XXX 

Frozen Goals : □ 

Goal : goal2. 

SIMULATIMG 

Cl. 1. 1. 1. 1] 

IXX XXX 

Frozen Goals :□ Constraints : □ 

Goal : goals. 


-SIMULATING- 


XXX 


Constraints : □ 
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SIMULATING' 

Cl. 2. 3. 4] 

Cl, 2. 3. 5] 

Cl. 2, 4. 3] 


C5, 4. 3. 1] 
C5. 4. 3, 2] 
Count ® 120 


Frozen Goals :□ 


XXX 


XXX 

Constraints : □ 
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Appendix D 

Test Programs which use 
Constraint Solvers 


D.l Testing real black-box solvers using RPC 

This program demonstrates that domain real solvers can be executing on any/or all 
of the machines, say in our case tejas and vayu. Also more than one real solver can 
be executing on the same machine with different program numbers for RPC’s. Any 
of these can be invoked by the user, simplify by specifying the name of the machine 
and the program number in the goal. 

/* Example 101 : AAK */ 

/* Checking of REAL black_box constraint solver on tejas or vayu 
for different constraint .prog’s. 

*/ 

goal ; - 

sriteC ’Please specify goaKMachineName.ConstraintProg) . ’) , 
writeC’eg: goalCtejas,99) . ’) ,nl, 
writeC’ goal<tejas,98) . ’) ,nl, 

write (’ goal (vayu, 99) . ’),nl. 

goal (MachineN ame , N) : ~ 

.f [real ,rpc , machine _name®HachineN ame , constraint .prog-Nj , 
CRealA+RealB=2 . 0 , RealA-RealB+RealC* 1 . 0] 

]}, 

RealC = 1.0, 

write( ’Solved ’) ,write(’RealA=’) ,write(RealA) , 

write ( ’ , RealB* ’ ) , write (RealB) , 
write(’ , RealC*’ ) ,write(RealC) ,nl. 

The output of this program on any of the solvers is : 

Solved RealA*1.0, RealB* 1.0, RealC*1.0 
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D.2 Using float and real solvers to demonstrate struc- 
ture independence 

This program is used to show that the domain of the constraints specified could 
be any domain. Thus the constraints are written independent of the domain thus 
showing structure independence. We have used float solver and the real solvers 
which are different domains. Real solvers require that the constants be atoms while 
float require them to be numeric. However the filter for the real solver takes care 
of converting the numeric constants to atoms on the solver side. Therefore the 
program works for either of the domains. 


/* Example 102 : AAK */ 

(* Checking of float, real solvers on tejas or vayu for any details 
specified directly by the user. Notice that the domain i.e. float 
or real may also be specified online by the user thus making the 
specifications structure independent. 

Also notice that unification is used for RealC with constraint 
solving for finding solutions for the three variables. 


*/ 

goal : - 

^ Plos-SQ specify gos.lCDG’ts.ilsOfSoXvsr) . *) >iil> 
write (’Examples: ’) ,nl, 

write(’ goal(float). '/, Default internal solver. ’) ,nl, 

writ6(’ goal(real). '/, Default remote tejas. ’),nl, 

write ( ’ goal( [real ,rpc ,machine.name=vayu] ) . ’ ) ,nl , 

write (’The complete list of details that could be’),nl, 
write (’specified when using rpcs is :’),nl, 

write(’ machine_name, constraint.prog, constraint.vers , ’ ) , 
writa(’ function.number, tcp_udp . ’ ) ,nl , 

writ 0 (’NOTE: This may also be used for incremental*) ,nl, 
write(’ solvers but fail must be given after the’),nl, 

write(’ goal to allow the incremental constraint *) ,nl , 

write (’ solver to go back to its original state. ’).nl. 

®°^{Sn^raStDetail! [RealA+RealB=2.0,RealA-RealB+RealC=l .0] 

]>. RealC = 1.0, . n 

write(’Solved ’ ) .write(’RealA=’) ,write(RealA) , 

write(’, RealB= ’), write (RealB), 
tirite(’ . RealC=’), write (RealC) ,nl. 


The output of the program is ; 

Solved RealA*1.0, RealB=1.0. RealC=1.0 


82 



D.3 Checking boolean black-box solver 

The boolean black-box solver is invoked through saine_fs strategy. The different 
goals illustrated below show normal solutions as well as backtracking. 


/* Example 103 : AAK */ 

/♦ Checking of boolean constraint solver */ 

y. Checking true solution 

goall 

write(X) ,write(’ ’) ,write(Y) ,nl, 

{[boolean, [(true and false) = X, true - (X or Y)]]>, 
write (’The values of X and Y are 
write(X) ,write(’ ’) .write (Y) ,nl. 

y. Checking whether variables are printed properly 
goal2 : - 

write(X) ,write(’ ’) ,write(Y) ,write(’ ’) ,write(Z) ,nl, 

{[boolean, [(true and false) * X, true = (X or Y or Z)]]}, 

write(’The values of X, Y and Z are :’), 

write(X) .write (’ ’), 

write(Y) ,write(’ ’), 

write (Z) ,nl. 

% Checking execution with fail 

goals 

writo(’ Checking whether true = false’), nl, 

{[boolean, [true = false]]}, 
write (’Checked that true = false. ’),nl. 
goals 

write(’True != False. ’),nl. 

The outputs are as follows : 


goall : 

The values of X and Y are : false true 


goal2 : 

_X _Y _Z 

The values of X. Y and Z are rfalse _Y 
Constraints : [[boolean. [=(true. or(_Y, 


_Z 

Jt))]]] 


goal3 : 

True != False. 


83 



D.4 Checking real incremental solver 

The incremental solver for domain real is simulated on the nonincremental solver by 
stacking constraints when a new constraint is added and unstacking for backtrack- 
ing. Though slow, it suffices to illustrate the working and interfacing of incremental 
solvers. Different goals are illustrated below : 

/♦ Example 104 : AAK */ 

/♦ CHECKING OF THE REAL INCREMENTAL SOLVER ON TEJAS */ 

goal writeC'Try goallO, goalll, goall2, and goall3. ’) ,nl. 


’/, Backtracking of incremental solver because of later fail. 
goallO;- 

■CCinc.real, CA+B=9.0]]}, 

«rite(’A after first step : ’) »write(A) ,nl, 
writeC’B after first step : ’) ,write(B) ,nl, 

•CCinc.real, CA-B=1.0]]}, 

writef ’Final values are : ’) ,write(A) ,nl,write(B) ,nl,fail. 
goal 10. 


I 

X Backtracking of incremental solver because of inconsistency 

7. and then because of fail. 

goalll 

goaltryl(A,B) , 

writeC’A after first step ; ') ,write(A) ,nl, 
writeC’B after first step : ’) ,write(B) ,nl, 

{[inc.real, [A-B=0.0]]}, 

write (’Final values are ;’) ,write(A) .write (’ 

write(B) ,nl, 

{[inc.real, [A+1.0=B]]}. 

/♦ Actually A = B, This causes fail. */ 

goalll true. 
goaltrylCA.B) 

■CCinc_real, CA+B=10.0]]3’- 
goaltrylCA.B) 

{ [inc_r eal , CA+B=8 . 0] ] } . 


\ Backtracking in solver in presence of cut-fail combination 

goall2 goall2a. 

goall2 goall2b,fail. 

goall2. 
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goal 12a 

•C [inc.real , CA+B=10 . 0] ] > , 

{ Cinc.real , CA-B=0 . 0] ] } , ! , 

write (’Final values are :’) ,write(A) .write (’ 

write(B) .nl.fail. 

goall2b:- 

•C Cinc.real , CA+B=10 . 0] ] > , 

{ Cinc.real , CA-B=2 . 0] ] } , 

writeC’ Fined values are : ’) .writeCA) .writeC’ ’), 

writeCB) ,nl. 


I 

/* The final fail in goall is to reset the state of the 
constraint solver to where it was when the program started. 

Notice that although there is a cut at the end of clause 2 
of work/3, the backtrack call is still given to the 
constraint solver because of fail in goall. Thus cuts have 
no effect on the correct sending of backtracking calls to 
the incremental solver thus allowing the solver to maintain 
its state correctly, even in presence of cuts. Thus correct 
backtrack cadis which were supposed to be . given to the 
incremental solver without the presence of cuts will also 
be given in the presence of cuts. 

*/ 

goall3 goal(bbb), fail. 

We may have a cut before the fail here, 
y. This also has no effect on backtrack calls to solver. 

7, Notice no clause to make go.al3 true, so Unsuccessful, 
y, but solver state is proper. 
goal(U) work(U,A,B), 

write(’A=’) ,write(A) ,nl,write(’B=’) ,write(B) ,nl. 
work (AAA, A, B) 

{[inc.real, [A+B=10.0, A-B=2.0]]>, AAA = aaa. 
work(BBB, A, B) 

{[inc.real, [A+B=10.0, A-B=6.0]]}, BBB = bbb,!. 
y. This will never be executed because of the cut in clause above, 
work (BBB, A, B) 

{[inc.real, [A+B=10.0, A-B=8.0]]}, BBB = bbb. 

y. 

The outputs for each of the goals is given below along with statements indicating 
what is happening internally. 

goall 1: 
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Solver called : Backtrack must be sent. 

A after first step : 

Solver called : 

Output command, so no backtrack must be sent for this. 

_A 

B after first step : 

Solver called : 

Output command, so no backtrack must be sent for this. 

+(9.0, *(-1.0, .A)) 

Solver called : Backtrack must be sent. 

Finail values are : 

Solver called : 

Output command, so no backtrack must be sent for this. 

5.0 

Solver called : 

Output command, so no backtrack must be sent for this. 

4.0 

Backtrack call given to incremental solver 
Backtrack call given to incremental solver 

The solutions of the other goals are given along with positions of backtrack calls. 

goall2 : 

Final values are : 6.0 5.0 

Backtrack call given to incremental solver 
Backtrack call given to incremental solver 
Final values are : 6.0 4.0 

Backtrack call given to incremental solver 
Backtrack call given to incremental solver 

goallS : 

Backtrack call given to incremental solver 
A= 8.0 
B= 2.0 

Backtrack call given to incremental solver 

D.5 Checking multiple solvers in action 

Quintus Prolog is invoked two times for this problem. The inference engine along 
with its float solver is executing on csesunl on the first invocation of Quintus Prolog. 
Domain boolean constraint solver is executing on csesunl on the second invocation 
of Quintus Prolog. Two similar Domain real constraints solvers are executing on 
tejas and vayu. 

Notice that : 
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1. The constraint variable RealC has been used across the two real constraint 
solvers, i.e. on tejas and vayu. RealC is passed to tejas as well as unified by 
the inference engine. 

2. The domain boolean solver by default talces the sameJs (same file system) 
method for communication through files. (Current default file number is 10). 

3. The domain real by default takes the tejas solver with rpc used for communi- 
cation. The constraint _prog is 99, constraint.vers is 1 and function-number is 
1. ‘tcp’ is used for rpc’s. 

4. Initially the boolean solver is called with BoolVal uninstantiated and later 
when BoolVal is unified with false, then the constraint gets solved by the 
boolean constraint solver. Thus there are multiple calls to the boolean con- 
straint solver. 

5. The float solver is attached to the inference engine and it is called more than 
once since the constraints are specified separately. 


goal 

Details = [real, rpc, mach.in 6 _namG=va 3 ru, 

constraint_prog=99 , 
constraint _vers=l , 
f unction_number=l , 
tcp_udp=tcp 

3 . 

{[boolean, [true ® ’"’(BoolVal)]], 

[Details, [FRealA+FRealB+FRealC=’4.0’ , 
FRealA-FRealB=’0.0’, 

FRealC=RealC-’1.0’]] , 

y, RealC gets bound to ’1.0’ because of above solver 
[real , [RealA+RealB=’2.0’ ,RealA-RealB+RealC=’ 1 .0’]] , 
[float , [Float A+FloatB+FloatC=6 .0, Float A-FloatB= -1.0]] 
}. 

BoolVal = false, RealC = ’1.0’, 

{[float, [FloatC-FloatB = 1.0]]}, 
write (’Solved :’),nl, 

write (’Boolean : ’), 

write(truG = ’"’ (BoolVal)) ,nl, 
write ( ’ RealVayu : ’ ) , 

write(’FRealA=’) .write (FRealA) , 
write(’, FRealB=’ ) ,write(FRealB) , 
write(’ . FRealC=’) .write (FRealC) ,nl, 
write (’RealTej as : ’), 

write (’ RealA= ’ ) .write (RealA) , 
write(’, RealB=’) ,write(RealB) , 
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write (’ , RealC=’) .write (RealC) ,nl, 
write (’Floatintemal : *), 

write(’FloatA=’) ,write(FloatA) , 
write C’ , FloatB=’) ,write(FloatB) , 
write C’ , FloatC=’) .write (FloatC) ,nl. 

The final output is as follows : 

Boolean : =*(true. "(false)) 

RealVayu : FRealA=2.0, FRealB=2.0. FRealC=0.0 

RealTejeis : RealA=1.0. RealB=1.0. RealC=1.0 
Float Internal : Float A=1.0. FloatB=2.0. FloatC=3.0 
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Appendix E 

VAM-Code 


The code is produced in a form that the simulator written in Prolog can understand. 
Thus the whole code is read as a single term. We have used internal codes as 
follows : v(l) for fstvar, v(2) for nxtvar, v(3) for constant, v(4) for struct and v(5) 
for list. We use temporary var for storing names but these are converted to internal 
variables before use. Also note that in the current implementation, we have used 
v(3), const(nill) instead for the instruction nil. 


E.l Code for Installments Capital Problem 

The VAM code produced by the compiler written using C (LEX and YACC) for the 
installments capital problem described in Figure 4.1 is shown here. 

['/.Procedure : 001 .Clause : 001===========“=========®============* 

vam_clauseC [v(3) , constCatomCC’goal’))), c.goal, 

v(4) , functor((’installments_capital’) ,2) , 

v(S) , v(l), temporaryvar(’I’) , 

vC5), v(4), functor((’*’) ,2), 

v(3) , const (real (2. 000000) ) , 

v(2) , temporaryvarC’I’) , 

v(5) , v(4), functor((’*’) ,2), 

v(3) , const (real (3. 000000) ) , 

v(2) , temporeLryvar(’I’) , 

v(3), const(’nill’) , 

v(3) , const (real (1000. 000000)), 

c.call, c_goal, 

v(4) , functor(( ’ write’ ) ,1) , 

v(3), const (str( ’Answer: 1=’)), 

c_call, c.goal, 

v(4), functor((’write’) ,1) , 

v(2) , temporaryvar(’I’) , 

c_call, c.goal. 
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v(3), const(atom((’nl’))) , 
c_lastcall] 

‘/.Procedure : 002 , Clause : 001===================================== 

vain_clauseC Cv(4) , functorCC ’installments.capital’ ) ,2) , 

v(5), v(l), temporaryvar(’I’) , 

v(l) , temporaryvar(’X’) , 

v(l), temporaryvar(’C’) , c.goal, 

v(4) , functor (C’merge_constraiiits’) , 1) , 

v(4), functor((’=’),2), 

v(l), temporaryvar(’Y’) , 

v(4), fTinctor((’-’),2), 

v(4), functorCC’*’) ,2) , 

v(3), const(realCl. 100000)) , 

v(2), temporaryvarC’C’) , 

v(2), temporaryvar(’I’) , 

c_call , c_goal , 

v(4) , functor(C’installments_capital’) .2) , 
v(2), temporaryv«ir(’X’) , 
v(2), temporsLryvairC’Y’) . 
c.lastcall] ,C’Y', ‘C’. »X’, ’I']), 

*!, Clause: 002 

vain_clause( Cv(4) , functor((’installments_capital’ ) ,2) , 

v(3), const (’ nill ’) » 

v(3) , const (real CO. 000000) ) , 

c.nogoal] , □ )] . 

E.2 Code for Permutations 

A part of the VAM code produced by the compiler for Example 13 in Appendix C 
is included here. 


‘/.Procediire : 011 , Clause : 001======“============================= 

vam_clause( [v(4) , functorCC ’length’ ) ,2) , 

v(l), temporaryvar(’L’) , 

v(l), temporaryvar(’N’) , c_goal, 

vC4), frmctorCC ’freeze’) ,2) , 

v(2), temporaryvar(’L’) , 

v(4), functorCC ’length_new’) ,2), 

vC2), temporaryvarC’L’) , 

vC2), temporaryvarC’N’) , 

c_lastcall] , C’N’ , ’L’]), 


90 



Appendix F 

Real World Programs using 
Solvers 

F.l Factorial 

The program for finding factorial is shown below : 

factorialCA.B) -CA=0.0,B=1.0}. 
f actorial(A,B) •CB=A*FactAminusl, Aminusl=A-l .0}, 

factorial(Aminusl,FactAininusl) . 

This simple factorial procedure uses constraints to : 

1. Find the factorial B of a given number A. e.g. goall,goal4 

2. Find the number A whose factorial B is given, e.g. goal2,goaI5 

3. (liven A and B, Check if number B is factorial of A. e.g. goals 

4. (Icnerate A and B both if both are variables e.g. goalO 
Each of the goals numbered 1 to 5 are shown below : 
goalO factorial(X,Y) , 

write (’Solution of factorial (X,Y) is X=’) ,write(X) , 
writeC’, Y=’) ,write(Y) ,nl,fail. 
goall factorial(3.0,X) , 

write (’Solution of factorial (3. 0.X) is X=’) ,write(X) ,nl. 
goal2 factorial(X,6.0) , 

write ( ’Solution of factorial(X,6.0) is X=’) ,write(X) ,nl. 
goals factorial(3. 0,6.0) , 

write( ’Solution of factorial (3. 0,6.0) is ’),nl. 
goal4 factorial(4.0,X), 

yri’te( ’Solution of factorial (4. 0,X) is X— ’) ,write(X) ,nl. 
goals factorial(X,24.0) , 

write (’Solution of factorial(X,24.0) is X=’) , write (X) ,nl. 
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Solutions for each of the above goals are as follows : 
goalO : 

Solution of factorial (X,Y) is X=0.0, Y=1.0 
Solution of factorial(X,Y) is X=1.0, Y=1.0 
Solution of fact6rial(X,Y) is X=2.0, Y=2.0 
Solution of factorial (X,Y) is X=3.0, Y=6.0 
Solution of f actor ial(X,Y) is X=4.0, Y=24.0 
Solution of factorial (X,Y) is X=5.0, Y=120.0 


goall: Time 
Solution 
goal2: Time 
Solution 
goals: Time 
Solution 
goal4: Time 
Solution 
goals : Time 
Solution 


taken: 0.767 sec 
of factorieil(3.0,X) is X=6.0 
taken: 3.683 sec 
of factorial(X,6.0) is X=3.0 
taken: 0.667 sec 
of factorial(3. 0,6.0) is 
taken: 0.967 sec 
of factoriaLl(4.0,X) is X=24.0 
taken: 8.234 sec 
of factorial(X,24.0) is X=4.0 


The factorial program has been extended below to handle even wrong factorials. 


fact_solve(FactOf .Value) :- 

numeric (FactOf) , ! , factorial(Fact0f, Value) . 
fact_solve(FactOf .Value) :- 

numeric (Value) , ! , loop (1.0, Value, FactOf ) . 
loop(X, Value, FactOf ) :- 

f actorial(X,Y) , check_fact(X,Y,Value,FactOf ) . 
check.f act (X,Y, Value, X) :- {Y=Value>,!. 
check_fact(X,Y, Value, FactOf) :- 

{Y<Value},!,NewX is X+1 .0, loop (NewX, Value, FactOf ) . 
check.f act (X,Y, Value, notPossible) :- {Y>Value},!. 
check.f act(X,Y,Y, FactOf ) :- 

numeric (X) , ninneric (FactOf ) ,X==Fact0f , ! . 
check.fact(X,Y,Value,FactOf ) :- 

numeric(X) ,numeric(FactOf ) ,X<Fact0f , ! , 

NewX is X+1 .0, loop (NewX .Value, Fact Of ) . 

The goals numbered 6 to 9 are used to test this as shown below : 

goal6 :- fact. solve (X, 6.0) , 

write( ’fact. solve(X, 6.0) gives X=’) ,write(X) ,nl. 
goal7 :- fact.solve(3.0,X) , 

write(’fact.solve(3.0,X) gives X=’) ,write(X) ,nl. 
goal8 :- f act. solve (3.0, 6. 0) , 
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write( ’f act_solve (3 . 0 , 6 . 0) gives ’ ) ,nl . 
goals fact_solveCX,7.0) , 

write(’fact_solve(X,7.0) gives X=’) ,write(X) ,nl. 

The solutions for the goals numbered 6 to 9 are given below : 

goals : Time taken: 3.266 sec 
fact_solve(X,6.0) gives X=3.0 
goal7: Time taken: 0.850 sec 
fact_solve(3.0,X) gives X=6.0 
gOeilS: Time taken: 0.717 sec 
fact_solve(3.0,6.0) gives 
goals : Time taken: 5.000 sec 

f act_solve(X,7.0) gives X=notPossible 


F.2 Complex numbers 

Shown below is a program for multiplying two complex numbers. 

/* Multiply complex numbers */ 
c_mult(cCRl,Il).c(R2,I2),c(R3,I3)) :- 

{R3 * R1 * R2 - II ♦ 12, 13 * R1 * 12 + R2 * II}. 
goail:- 

c_mult(c(1.0, 1 .0) ,c(2.0,2.0) ,Z) , 
c_mult(c(1.0,1.0),Y.c(0. 0,4.0)) . 
c_mult(X,c(2.0,2.0) ,c(0.0,4.0)) , 
write(X) ,nl,write(Y) ,nl,write(Z) ,nl. 

The solution for the above goal is : 

cCl.O, 1.0) 
c(2.0, 2.0) 
c(-0.0, 4.0) 

Time taken : 0.150 sec 

F.3 Light Meals Problem - Let’s Eat Well 

Consider a problem to devise a possible set of light meals. Let H be the appetizer 
(horsDceuvre), M be the main course and D be the dessert. Then the triplet H,M,D 
is a meal. The light meal is defined by assigning a certain number of caloric units to 
each course and restricting itself to meals that add up to a number of units smaller 
than 10. The listing of the program for devising light meals is shown below : 

/♦ Computing Light meals */ 
light_meals(H,M,D) :- 

■C[real,Cl>=0.0,J>=0.0,K>=0.0,I+J+K=<10-0]]>, 
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horsDceuvre (H , I ) , 
mainCourss(M, J) , 
dessert (D,K) . 

mainCourse(M,I) :-meat(H,I) . 
mainCourse(M,I) :-fishCM,I) . 

horsDceuvre (radishes ,1.0). 
horsDceuvre (pate , 6 . 0) . 

meat (beef ,5.0) . 
meat (pork, 7.0) . 

f ish(sol6,2.0) . 
f ish(tuna,4.0) . 

dessert (fruit, 2.0) . 
dessert (icecream, 6.0) . 

goal 

light_meals(H,M,D) , 

write ( ’H=0, write (H), 

write(’, M=’) ,write(M) , 

write(’, D®’) .write (D) ,nl, 

fail. /* For listing all solutions */ 

The query light jneals(H,M,D) in the goal above allows us to obtain all the sets of 
H, M and D that constitute a light meal. In this case there are six replies. The 
solutions are listed below : 

H=radishes, M=beef, D=fruit 
H=radishes, M=pork, D=fruit 
H=radishes, M=sole, D=fruit 
H=radishes, H=sole, D=icecream 
H=radishes, H=tuna, D=fruit 
H=pate, M=sole, D=fruit 

Time taken for the above problem on the internal float solver is 4.116 sec. In 
the predicate light jmeals above, the constraints are set up at the very beginning. 
Thus, the same constraints will be checked again and again, initially with variables 
unbound and later when the variables get bound. This seems to introduce a lot of 
overhead over the normal method we would use to write the same program in Prolog 
in which the constraints would be checked at the end of the predicate light jmeals 
after all variables have been bound as shown below ; 

light_meals(H,M,D) 
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horsDceuvre(H,I) , 
mainCourse (M , J) , 
dessert (D, K) , 

I>=0.0,J>*0.0,K>=0.0,I+J+K=<10.0 . 

*/. or {[real, Cl>=0.0,J>=0.0,K>=0.0,I+J+K=<10.0]]}. 

This is the generate-and-test technique. Time taken, on the internal float solver 
is 3.417 sec. The inefficiency is present in this small example which is used only 
to demonstrate the use of constraints. However, for larger problems this forward 
checking with the help of constraints increases the efficiency of the program since 
incorrect values are never selected. This is illustrated in the next example. 


F.4 Cryptarithmetic puzzle 

Consider the classical cryptarithmetic addition program. For given strings of letters 
"SEND”, ’’MORE” and ’’MONEY”, each of which, represent different integers from 
0 to 9, the problem is to find an appropriate assignment of digits for each letter so 
that adding the numbers represented by "SEND” and ’’MORE” yields the number 
represented by ”MONEY”. Consider a Prolog program using the generate and test 
strategy for solving the above puzzle. 

solution([S,E,N,D] . [M,0,R,E] , [M,0,N.E,Y]) 

admissible(Rl,0,0,M,0) , admissible(R2,S,M,0,Rl) , 
admissible(R3,E,0,N,R2) , admissibl6(R4,N,R,E,R3) , 
admissible(0,D,E,Y,R4) , 
without _repet it ion ([S,E,N,D,M,0,R,Y]), 

M \== 0. S \== 0. 

admissible(R,X,Y,Z,Rl) 

remainder (R) , digit(X), digit(Y), 

T is R+X+Y, R1 is T/10, Z is (T mod 10). 

remainder (0) . 

remainder (1) . 

digit (0) . 

digit (9) . 

without _repetition( □ ) . 

without_repetition([X|Y]) out_of(X,Y), 
without_repetition(Y) . 

out_of cx, n ) • 

out_of (X, [AlL] ) X \== A, out_of(X,L). 

This program is inefficient under Prolog’s standard left to right control rule. The 
program is rewritten using forward checking with the help of constraints as shown 
below : 
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the process. This shows that the use of coroutining helps in finding the solutions 
faster. The solution to this problem may also be rewritten using the predicate dif 
instead of constraints by using the predicate freeze, because all that is required is 
that is of the values assigned to S, E, N, D, M, 0, R, Y are different. The the 
definition of out_of will be : 

out_of(_,n) !. 
out_of(U,CV|W]) 

out.of(U,W), dif(U, V). 
difCX.Y) freezeCX, freeze(Y, X \== Y)). 

Also instead of S \== 0 and M \== 0 in clause for solution we use dif(S,0) amd 
dif(M,0) respectively. The same solutions axe obtained. 

F.5 Computing Scalar Products 

The following program is used to compute scalar products. 

/* Computing Scalar Products */ 

/* Refer Pg 79, CACM July 90 */ 
scalar.productCD ,□ .Value) ■CValue=0 . 0} . 

scalar_product( [Xl |X] , [Y1 I Y] ,W) 

{W1=X1*Y1,W=W1+Z}, 
sc 2 d.«ir_productCX,Y,Z) . 
goal 

scalar .product ([1.0, 1.0] ,X,12.0) , 
scalar.productCX, [2. 0,4.0] ,34.0) , 
writeC’Answer is X = ’) »write(X) ,nl. 

The solution of goal above is : 

Answer is X = [7.0, 5.0] 

Time taken: 1.033 sec 


F.6 Trajectory Problem 

The problem is to find the points on the trajectory. 

traj ([_,_]). 
traj([Hm, H, HplT]):- 

merge.constraintsC , (Hp-H=H-Hm-G,G=1 . 0) ) , 
traj([H,HplT]). 
goal 

XI is 0.0, XIO is 5.0, 
traj([Xl,X2,X3,X4,X5,X6,X7,X8,X9,X10]), 
write(’Xl=’ ) ,write(Xl) ,nl. 


97 



write(’X2='),write(X2),nl, 
write(’X3=0 ,write(X3),nl, 
write(’X4=') ,writG(X4),nl, 
writG(’X5=’) .writeCXS) ,nl, 
write(’X6=’) .writeCXS) ,nl, 
wr it e ( ’ X7= 0 . writ e (X7 ) , nl , 
writG(’X8=’) ,write(X8) ,nl, 
writG ( ’ X9= ’ ) . writ G (X9) ,nl , 
writG(’X10=’) ,writG(X10) ,nl 

Solutions axe : 

X1=0.0 

X2=4. 55555 

X3=8.1111 

X4=10.6666 

X5=12.2222 

X6=12.7777 

X7=12.3333 

X8=10.8888 

X9=8.4444 

X10=5.0 

TimG taken: 4.766 sgc 


F.7 Circuit Solver 

Note : This file will be loaded by dc_circl and dc_circ2 independently. The con- 
straints will be solved by the float solver attached to the inference engine on the 
client itself. The constraints will not be passed to any remote machine. 

This program carries out a steady state phasor analysis of RLC circuits. It is 
called through the predicate circuit-solve() which has arguments : 

• the angular frequency for the analysis. 

• the component list. 

• the list of nodes which are to be ‘grounded’ - otherwise all voltages are relative. 

• the ‘Selection’ list - a list of nodes for which computed information is to be 
printed. 

The circuit is defined by a list of components. Each component is described by 
the component type, name, value and the nodes to which it is connected. The 
component type is used to determine the component characteristics. 

circuit _solVG (W ,L , G , Select ion) : - 
get_node_v 2 ors(L,NV) , 
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write (’Returned from get_node_vaxs’) ,n.l, 

write(L),nl,write(NV) 

c_solve(W,L,NV, Handles, G) , 

write (’Returned from c.solve’) ,nl, 

write(’W=’) ,write(W) ,nl, 

write ( ’ L= ’ ) .write (L) ,nl , 

write(’NV=’) ,writ6(NV) ,nl, 

write ( ’ Handles= ’ ) , write (Handles ) ,nl , 

write(’G=’) ,write(G) ,nl,! , 

format .print (Handles, Select ion) . 

f ormat .print (Handles , Selection) 

write(’ COMPONENT CONNECTIONS TO NODE ’ ) ,write(Selection) ,nl, 
! .write.L (Handles) ,nl. 

write.L(D) nl. 

write.L ( [[Component .Name .Value , 

[Nodel,c(Cl,C2),c(C3,C4)] ,[Node2.c(C5,C6),c(C7,C8)]] IXI]) 
write (Component) , write(’,’), write(Name), write(’,’), 
writeValue (Component .Value) ,nl, 
write ( [Nodel , c (Cl . C2) , c (C3 ,C4)] ) ,nl , 
write([Node2,c(CS,C6) ,c(C7,C8)] ) , 
nl,write.L(Xl) . 

write.L ( [[Component .Name .Value , 

[Nodel, c(Cl,C2) ,c(C3.C4)] , [Nod62,c(C5.C6) .c(C7,C8)] . 
[Node3,c(C9,C10) ,c(Cll,C12)] 

]|X1]) 

write (Component) , write ( ’ , ’) .write (Name) .write (’ , ’ ) , 
writeValue (Component .Value) ,nl , 
write([Nodel,c(Cl,C2) ,c(C3,C4)]) ,nl, 
write([Node2,c(C5,C6) ,c(C7,C8)]) ,nl, 
write( [Nodes, c(C9, CIO), c(Cll,C12)]),nl, 
write.L (XI) . 

write.L ( [ [Component , Name .Value , 

[Nodel, c(Cl,C2) ,c(C3,C4)] , [Node2 , c (C5 , C6) ,c(C7,C8)3 . 

[Nodes, c(C9, CIO), c(Cll.C12)].[Node4,c(C13,C14).c(C15,C16)] 
]1X1]) 

write (Component) ,write( ’ , ’) .write (Name) .write (’ , ’) , 

writeValue(Component .Value) ,nl , 

write(JlNodel ,c(Cl,C2) ,c(C3,C4)]) ,nl, 

write( [Node2,c(C5,C6) ,c(C7,C8)]) ,nl, 

write([Node3,c(C9,C10),c(Cll,C12)]),nl, 

write ( [Node4,c(C13,C14) ,c(C15,C16)]) ,nl, 

write.L (XI) . 
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writeValue (transformer. Value) 

writeC’ratio of ’) .write (Value) . 
writeValue (resistor, Value) 

write(Value) ,write(* Ohms’),!. 
writeValue (diode, Value) 

write(’type ’) ,write(Value) ,! . 
writeValue (voltage.source. Value) 
write(Value) ,write(’ Volts’),!. 
writeValue (inductor. Value) 

write(Value) ,write(’ Henry’),!. 
writeValue (capacitor. Value) 

write (Value) , write ( ’ Farads ’ ) , ! . 
writeValue (X, Value) 

write(Value) ,write(’ unknown’). 

get_node_vars (□,□). 
get_node_vaLrs( C[Comp,Num,X,Ms] |Ls] ,NV) 
get_node_vars(Ls,NVl) , 
insert .list (Ns, NVl.NV) . 

insert_list( □ ,NV,NV) . 
insert_list([N|Ns],NVl,NV3) 
insert. list (Ns, NV1,NV2) , 
insert (N,NV2,NV3). 

insert(N, □, [CN,V,c(0.0,0.0):] ) !. 

insert(N, [[N.V.I] |NV1] , [[N,V,I] |NV1] ) !. 

insert(N, [[Nl .V.I] |NV1] . C[N1 .V,I] |NV2]) 
insert (N,NV1,NV2). 

c.solve(W. [X|Xs],NV,[HlHs] ,G) 
addcomp(W,X,NV,NVl,H) , 
c.solve(H.Xs,NVl,Hs,G) . 
c.solve(W.n,NV,n.G) 

write (’********Checking for zero currents’) ,nl, 
debug.zero.currents(NV) , 
write(’********Currents are zero’), nl, 
ground.nodes (NV , G) . 

debug.zero. currents (NV) zero.currents(NV) . 

debug.zero. currents (NV) write( ’Backtracking’ ) ,nl,f ail. 

zero.currents(CCN,V,c(A,B)] |Ls]) 

{ [float , [A=0 . 0 ,B=0 . 0]] } .zero. currents (Ls) . 
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zero.currents ( □ ) . 


ground_iiodes (Vs , [N | Ns] ) 

grovmd.nodeCVs ,N) , ground.nodes (Vs ,Ns) . 
ground_nodes (Vs , □ ) . 
ground_node(CCN,c(0.0,0.0) ,1] iVs] ,M) . 
ground.node ( C [Nl , V , I] 1 Vs] , N) : - gromd_node (Vs , N) . 

/* Rules to define component charactersitics */ 
addcomp(W, [Comp2, Num, X, CN1,N2]] ,NV,NV2, 

[Comp2, Num, X, [Nl.Vl,!!] , [N2,V2,I2]] ) 
write ( ’ Adding ’ ) ,write(Comp2) ,nl , 
c_neg(Il,I2) , 

iv_reln(Comp2, II, V, X, W) , 
c_add(V,V2,Vl), 

subst(CNl,Vl,Ioldl] , [Nl,Vl,In6wl] ,NV,NV1) , 
subst ( CN2 , V2 , Iold2] , CN2 , V2 , Inew2] , NVl , NV2) , . 
c_add(Il,Ioldl,Inewl) , 
c_add(I2,Iold2,Inew2) . 

/* Specific current /volt age relations for the 
two terminal components */ 
iv_reln(rasistor,I,V,R,W) 
c_mult(I,c(R,0.0) ,V) . 
iv_reln(voltage_source,I,V,V,W) . 
iv_reln(isource,I,V,I,W) . 
iv_reln(capacitor,I ,V,C,W) 
c.mult(c(0.0,W*C),V,I) . 
iv_reln(inductor,I,V,L,W) 
c.mult(c(0.0,W*L),I.V) . 
iv_reln(connection,I,c(Constl,Const2) ,L,W) 

{Const 1=0 . 0 , Const2=0 . 0} . 
iv_reln(diode,I,V,D,W) diode(D,I,V) . 

/* three rules per diode type */ 
diode(in914, c(10.0*DV,0.0) , c(V,0.0)) 

{ [float , [V< -100.0 ,DV=V+100 . 0] ] } . 
diode(in914, c(0.0010*V,0.0) , c(V,0.0)) 

{[float, [V>= -100.0,V<0.60]]}. 
diode(in914, c(100.0*DV,0.0) , c(V,0.0)) 

{ [f loat , [V>=0 . 60 , DV=V-0 . 60] ] > . 

addcomp(W, [transistor, Nm, X, [N1,N2,N3]], NV, NV3, 
[transistor, Num, X, [N1,V1,I1], 
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[N2,V2,I2].[N3,V3,I3]]) 
write (’Adding transistor’) ,nl, 
transistor (X,R, Gain) , 
c_add(Il,I3,IT), 
c_negCl2,IT) , 
c.add(Vin,V2,Vl), 
c_mult(Il,c(R,0.0) ,Vin) , 
c.multCll ,c(Gain,0.0) ,13) , 
subst(CNl,Vl,Ioldl] , CNl,Vl,Inewl] ,NV,NV1), 
subst([N2,V2,Iold2] , [N2,V2,Inew2] ,NV1,NV2) , 
subst([N3,V3,Iold3] . [N3,V3,Inew3] ,NV2.NV3) , 
subst ( CN4 , V4 , Iold4] , CN4 , V4 , Inewl] . NV3 , NV4) , 
c_add(Il,Ioldl,Inewl) , 
c_addCl2,Iold2,Inew2) , 
c_add(I3,Iold3,Inew3) , 
c_add(I4,Iold4,Inew4) . 

t* one for each kind of transistor we wish to consider */ 
transistorCbclOS, 1000.0, 100.0). 

addcompCW, [transformer, Num, X, CN1,N2,N3,N4]] , NV, NV4, 
[transformer, Num, X, [N1,V1,I1] , [N2,V2,I2] , 

[N3,V3,I3],[N4,V4,I4]3):- 
write ( ’ Adding transformer ’ ) ,nl , 
c_neg(Il,I2) , 
c_neg(I3,I4) , 
c_add(Vin,V2,Vl), 
c_add(Vout,V4,V3), 
c_mult(Vout ,c(X,0.0) ,Vin) , 
c_multCll,c(X,0.0),I4), 

subst C [N1 , VI , loldl] , [N1 ,V1 , Inewl] , NV ,NV1) , 
subst ( [N2 , V2 , Iold2] , [N2 ,V2 , Inew2] , NVl , NV2) , 
subst ([N3,V3,Iold3] , [N3,V3,Inew3] ,NV2,NV3) , 
subst ( [N4 , V4 , Iold4] , [N4 , V4 , Inew4] , NV3 , NV4) , 
c_add (II, loldl, Inewl), 
c_add(I2,Iold2,Inew2) , 
c_add(I3,Iold3,Inew3) , 
c_add(I4,Iold4,Inew4) . 

subst([A,Cl,C3],Y,[[A,C2,C4] |Ll],[YlLl]) 
c.eq(Cl,C2), c_eq(C3,C4). 

subst(X,Y,[Z|Ll],[Z|L2]) subst (X,Y, LI, L2) . 

/* Complex number aurithmetic */ 
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D1 


ground 

Figure F.l: Use of a general package to solve a circuit 


c_mult(c(Rel,Iml) , c (Re2 , Im2) ,c(NewRe,N6wIm) ) 

■[ [float , [NewRe=Rel*Re2-Iial*Im2 ,NewIm=Rel*Im2+Re2*Iml]] ]■ . 
c_add(c(Rel,Iml) ,c(Ra2,Im2) ,c(NGHRe,}lGwIm)) 

{ [float , [NeBRG®Rel+Re2 ,NeHlm=Iml+Iin2]] } . 
c_nGg(c(RG,Im) ,c(NGwRG,NGwIm)) 

{[float , [N gwRg = -RG.NewIm - 
c_Gq(c(RGl,Iml) ,c(Re2,Im2)) 

{ [float , [R g1=Rg 2 , Iml=Im2] ] } . 
c_rGal(c(Re,Im) ,Re) . 
c_imag(c(RG,Im) ,Im) . 

F.7.1 dc_circl 

Consider the problem shown below : 
goal 

{ [float , [W=0 . 0 , Vs=10 . 0 , Rl=100 . 0 ,R2=50 . 0 ,Const=0 .0] ] > , 
circuit _ so1vg(W, 

[[voltage_source,vl,c(Vs, Const) , [nl, ground]] , 

[resistor, rl,Rl . [nl,n2]] , 

[resistor,r2,R2, [n2, ground]] , 

[diode, dl, in914, [n2, ground]] 

], 

[ground] , 

[n2]). 

The solution obtained is : 

voltagG_sourcG , vl , c ( 10 . 0 , 0 . 0) Volts 
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[nl.cClO. 0,0.0) ,c(-0. 0939918, 0.0)] 

[ground, c(6.66134e-16,0.0),c(0. 0939918, 0.0)] 
resistor, rl, 100.0 Ohms 
Cnl,cCl0.0,0.0),cC0. 0939918, 0.0)] 

[n2 , c (0 . 60082 , 0 . 0) , c ( -0 . 0939918 ,0.0)] 

resistor,r2,50.0 Ohms 

[n2,cC0. 60082, 0.0),c(0. 0120164, 0.0)] 

[ground, c(0.0,0.0),c(-0. 0120164, 0.0)] 

diode, dl, type in914 

[n2,c(0. 60082, 0.0),c(0. 0819754, 0.0)] 

[ground, c(0. 0,0.0) ,c(-0 .0819754,0.0)] 

F.7.2 dc_circ2 
goal 

i [float , [W=100 . 0 , Vs=10 . 0 , 

Trl=5.0,Tr2=0.2, 

Rl=200 . 0 , R2= 1000 . 0 , R3=S0 . 0 , R4=30 . 0 , 

C1=0 . 05 ,L1=0 . 005 , Const=0 . 0] ] 

}. 

circuit_solve(W, 

[[voltage.source, vl, c(Vs, Const), [in,groTmdl]] , 
[resistor, rl, Rl, [in,nl]] , 

[transformer, tl, Trl, [nl,groundl, n2, ground2]] , 
[resistor, r2, R2, [n2,n3]], 

[capacitor, cl. Cl, [n3, n4]], 

[resistor, r3, R3, [n4, ground2]], 

[transformer, t2, Tr2, [n4, ground2, out, ground3]] , 
[resistor, r4, R4, [out, grounds]], 

[inductor, 11, LI, [out, grounds]] 

]. 

[groundl , ground2 , grounds] , 

[out] ) . 

The solution obtciined is : 

volt age.source , vl , c (10 . 0 , 0 . 0) Volts 
[in , c ( 10 . 0 , 1 . 35525e-20) , c (-0 . 000396825 , -7 . 08639e-08) ] 
[groundl , c (0 . 0 , 1 . 35525e-20) , c (0 . 000396825 , 7 . 08639e-08) ] 
resistor,r 1,200.0 Ohms 

[in , c ( 10 . 0 , 1 . 35525e-20) , c (0 . 000396825,7 . 08639e-08)] 

[nl , c (9 . 92063 , - 1 . 41728e-05) , c ( -0 . 000396825 , -7 . 08639e-08) ] 
transformer,tl, ratio of 5.0 

[nl , c (9 . 92063 , - 1 . 41728e-05) , c(0 .000396825 , 7 . 08639e-08)] 
[groundl , c (0 . 0 , 0 . 0) , c(-0 . 000396825 , -7 . 08639e-08)] 
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R1 R2 Cl 



groundl gro\md2 grounds 


Figure F.2: RLC circuit 

[n2 , c ( 1 . 98413 , -2 . 83456e-06) , c (-0 . 00 198413 , -3 . 5432e-07) ] 

Cground2 , cCO . 0 , -3 . 52366e- 18) , c(0 . 00198413 , 3 . 5432e-07)] 
resistor, r2, 1000.0 Ohms 

Cn2 , c ( 1 . 98413 , -2 . 83456e-06 ) , c (0 . 00 1984 13 , 3 . 5432e-07) ] 

[n3 , c (7 . 40831e-07 , -0 . 000357154) , c (-0 . 00198413 , -3 . 5432e-07) ] 
capacitor, cl, 0.05 Farads 

Cn3 , c (7 .40831e-07 , -0 . 000357154) , c (0 . 00198413 , 3 . 5432e-07)] 

[n4 , c (6 . 699678-07 , 3 . 967 lle-05) , c (-0 . 00 198413 , -3 . 5432e-07)] 
rGsistor,r3,50.0 Ohms 

Cn4 , c (6 . 69967e-07 ,3.967 lle-05) , c ( 1 . 33993e-08 , 7 . 93422e-07) ] 

[ground2, c(-l . 73536e-19 ,0 . 0) , c(-l . 33993e-08 ,-7 . 93422e-07)] 
transfoimer,t2, ratio of 0.2 

Cn4,c(6 .699678-07,3.967118-05) ,c(0 .00198411,-4.391028-07)3 
[ground2 ,c (0.0, 0.0) ,c(-0. 00198411 ,4.39 102 g- 07)3 
[out , c (3 . 34983e-06 , 0 . 000198355) , c ( -0 . 000396823 , 8 . 78204e-08) ] 
[ground3 , c (8 . 67362e-19 , 0 . 0) , c (0 . 000396823 , -8 . 78204 g- 08)] 
rGsistor,r4,30.0 Ohms 

[out, cC3. 349838-06,0. 000198355), c(l. 116618-07, 6. 611858-06)3 
[ground3,c(0.0,0.0),c(-l. 116618-07, -6. 611858-06)3 
inductor, 11 ,0.005 Henry 

[out , c(3 . 34983e-06 , 0 . 000198355) , c (0 . 000396711 , -6 . 69967 e-06) 3 
[ground3,cC0 .0,0.0) ,c(-0. 000396711 ,6 .699678-06)3 

F.8 Dirichlet Problem 

The following problem solves the Dirichlet problem for Laplace’s equation in two- 
dimensions. The program outputs a matrix (list of lists) giving the temperature of 
a surface at discrete points. Typical input is a matrix which contains specific values 
at the four boundaries. The program then specifies that the temperature at each 
non-boundary point is the average of those of four neighbouring points. 
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laplace(CHl,H2,H3|T]) 
av(Hl,H2,H3). 
laplace(CH2.H3|T]). 
laplace ([.,_]) . 

av(CTL,T,TR|Tl],[ML.M,MR|T2].CBL.B,BR|T3]) 
{B+T+ML+MR-4 . 0*M=0 . 0} . 
av ( [T ,TR I Tl] , [M .MR | T2] . [B ,BR 1 T3] ) . 
avCL. 

write (’last av’).nl. 
goall /* dirichletl */ 


> 

11 

1 — 1 





[0.0, 

0.0, 

0.0, 

0.0, 

0.0], 

[100.0, 

R. 

S, 

T, 

100.0], 

[100.0, 

U, 

V, 

W, 

100.0] , 

[100.0, 

X, 

Y, 

Z, 

100.0], 

[100.0, 

100.0, 

100.0, 

100.0, 

100.0] 


]. 

laplace (A) , 
write (A) ,nl,nl. 


Result : CCO.O, 0.0, 0.0, 0.0, 0.0], 

[100.0, 57.1429, 47.3215, 57.1426, 100.0], 

[100.0, 81.2501, 75.0005, 81.2485, 100.0], 

[100.0, 92.8571, 90.1787, 92.8574, 100.0], 

[ 100 . 0 , 100 . 0 , 100 . 0 , 100 . 0 , 100 . 0 ] 

] 


goaLl2 /* dirichlet2 */ 


A=[ 

[0.0, 0.0, 

0.0], 

1 — 1 

o 

o 

b 

>< 

100.0] 

[100.0, B, 

100.0] 

], 


laplace (A) , 
write (A) ,nl,nl 



Result : [[ 0.0, 0.0, 0.0], 

[100.0, +(50.0, *(0.25, _B)), 100.0], 

[100.0, _B, 100.0] 

] 
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Appendix G 

Scanner and Parser for 
Compiling Clauses 


G.l Scanner 

/* Terminals gl-ven by scanner in LEX */ 

Xright _atom 
Xright _qdash _if 
'/.right .semicolon 
'/.right .comma 

'Aright .is .unl'v .equal .not. equal 

Aloft .less.than .equal.to_less.than .greater. than.equal.to 
.great er_ than 
Aright .eequal _not_eequal 
'/.left .minus .plus 
'/.left _idiv .sL-ash .asterix .mod 
Aright .not 

Aright UNARY_miiius UNARY.plus 

'/.token .char _var .real _int _str .error 

Atoken .period _tail_sym 

'/.token _open.ro-und_bracket .close.round.bracket 
'/.token _open_sq.iiare_bracket .close.square.bracket 
'/token .open. CTiarly .bracket .close.curly .bracket 

G.2 Parser 

/♦ Grammar for Parser in YACC */ 

PGM: 

I 

PGM CLAUSE 
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CLAUSE: 


_qdash _open_s<juare_brack6t _atom 
_close_square_bracket .period 
I _if _open_square_bracket .atom 
.close.square.bracket .period 
1 EXPRESSION TAIL .period 
> 

EXPRESSION: 

LITERAL 

1 EXPRESSION .atom EXPRESSION 
1 EXPRESSION .is EXPRESSION 
I EXPRESSION .univ EXPRESSION 
1 EXPRESSION .equal EXPRESSION 
I EXPRESSION .not.equal EXPRESSION 
1 EXPRESSION .less. than EXPRESSION 
1 EXPRESSION .equal.to.less.than EXPRESSION 
I EXPRESSION .greater.than.equal.to EXPRESSION 
1 EXPRESSION .greater.than EXPRESSION 
1 EXPRESSION .eequal EXPRESSION 
I EXPRESSION .not.eequal EXPRESSION 
I EXPRESSION .minus EXPRESSION 
I EXPRESSION .plus EXPRESSION 
1 EXPRESSION .idiv EXPRESSION 
I EXPRESSION .slash EXPRESSION 
I expression .asterix EXPRESSION 
I EXPRESSION .mod EXPRESSION 

1 .plus EXPRESSION ‘/.prec UNARY.plus 

I Iminus EXPRESSION '/.prec UNARY.minus 

I Inot EXPRESSION 

1 "if .open.round.bracket EXPRESSION .comma 
EXPRESSION .close.round.bracket 
1 .semicolon .open.round.bracket EXPRESSION .comma 
expression .close.round.bracket 
I .comma .open.roxind.bracket EXPRESSION .comma 
expression .close.round.bracket 
1 .is .open_round.bracket EXPRESSION .comma 
expression .close.round.bracket 
1 .univ .open.round.bracket EXPRESSION .comma 
expression .close.round.bracket 
I equal .open.round_bracket EXPRESSION .comma 
expression .close.round.bracket 

1 not.equal _open.round.bracket EXPRESSION .comma 

expression .close.round.bracket 
1 .less.than .op en.r ound.br acket EXPRESSION .comma 
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EXPRESSION _clos 0 _round_bracket 
I _equal_to_less_than. 

_open._round_braclcet EXPRESSION .comma 
EXPRESSION _close_rouiid_bracket 
I _greater_than_equal_to 
_open_round_bracket EXPRESSION .comma 
EXPRESSION .close.round.bracket 
I .greater. than 

.open.round.bracket EXPRESSION .comma 
EXPRESSION .clos e_round.br acket 
I .eequal .open.round.bracket EXPRESSION .comma 
EXPRESSION .close.round.bracket 
1 .not.eequal .open.round.bracket EXPRESSION .comma 
EXPRESSION .close.round.bracket 
I .minus .open.round.bracket EXPRESSION .comma 
EXPRESSION .close.round.bracket 
I .plus .open.round.bracket EXPRESSION .comma 
EXPRESSION .close.round.bracket 
I _idiv .open.round.bracket EXPRESSION .comma 
EXPRESSION .close.round.bracket 
I .slash .open.round.bracket EXPRESSION .comma 
EXPRESSION .close.round.bracket 
I .asterix .open.round.bracket EXPRESSION .comma 
EXPRESSION .close.round.bracket 
I .mod .open.round.bracket EXPRESSION .comma 
EXPRESSION .close.round.bracket 
I 

LITERAL: 

_int 
I .real 
I .char 
I _str 

I .open.curly .bracket COMMAD.EXPRESSION 
.close.curly .bracket 
I .open.round.bracket EXPRESSION .if 
COMMAD.EXPRESSION .close.round.bracket 
I .open.round.bracket EXPRESSION .semicolon 
EXPRESSION .close.round.bracket 
I .open.round.bracket COMMAD.EXPRESSION 
.close.round.bracket 
I VARSYM 

I .atom PROCESSATOM 
I LISTLITERAL ; 

COMMAD.EXPRESSION : 


109 



COMMAD.EXPRESSION .comma COMMAD.EXPRESSION 
I EXPRESSION ; 

PROCESSATOH: PARLIST ; 

PARLIST : _open_round_bracket ARGLIST _close_round_bracket 

I ; 

ARGLIST: TERM ARGTAIL ; 

ARGTAIL : .comma ARGLIST 

I ; 

TERM: EXPRESSION ; 

VARSYM: .var ; 

TAIL: .if LITLIST I ; 

LITLIST: EXPRESSION LITTAIL ; 

LITTAIL:. comma LITLIST I ; 

LISTLITERAL: 

.open.square.bracket LISTELEMENTS 
. close. squeire.bracket ; 

NONNULLLISTELEMENTS : 

TERM LISTELEMENTSLIST ; 

NULLLISTELEMENTS: ; 

LISTELEMENTS: 

NONNULLLISTELEMENTS 
1 NULLLISTELEMENTS ; 

LISTELEMENTSLIST: 

.comma NONNULLLISTELEMENTS 
I .tail.sym LISTCDR 
I NULLLISTELEMENTS ; 

LISTCDR: VARSYM 

I LISTLITERAL ; 



